- ntg-pdftex - NTG Mailing Lists

pdftex-1.40.8
by Thanh Han The 10 Jul '08

10 Jul '08

Hi, a new stable release is available at http://sarovar.org/frs/download.php/1238/pdftex-1.40.8.tar.bz2 -------------------------------------------------- pdfTeX 3.1415926-1.40.8 was released on 2008-07-10 -------------------------------------------------- - Incorporated synctex - Incorporated the new version of TeX: 3.1415926 - The pool file is now compiled in - Bugfix: - some large TrueType fonts caused pdftex to segfault (1866) - fix for copying contents streams of included pdf (1751) - Fonts from included PDFs for which maplines existed missed their /StemV values - \pdflastximagepages was broken for JBIG2 images - included PDFs with a negative lly in the MediaBox with a depth != 0 with \pdfximage were wrongly vertically diplaces (936) - PDF inclusion was broken on ppc-darwin (941) - pdfTeX uses libpng 1.2.29 Thanh

1 0

CID Type 0C :-(
by Martin Schröder 03 Jul '08

03 Jul '08

Hi, a customer has a large number of documents (mostly from InDesign) with embedded CID Type 0C and CID TrueType fonts which get included by pdfTeX. Since pdfTeX doesn't do subsestting of these type of fonts, the number of fonts in the resulting PDF becomes quite large; too large for the tools of the printing house. My understanding is that this wouldn't happen if the included PDFs would instead use Type 1(C) fonts. Short of recreating/manipluating all those documents in InDesign to exchange the fonts (if possible at all), are there other options? Are there tools (e.g. PitStop) that can reliably exchange the fonts? And last but not least: How hard would it be to enhance pdfTeX to also subset CID Type 0C or CID TrueType fonts? Best Martin

1 0

[pdftex-Feature Requests][317] Add spaces to PDF file so reflow works..
by pdftex-featurerequests＠sarovar.org 28 Jun '08

28 Jun '08

Feature Requests item #317, was opened at 2005-03-23 12:43 Status: Open Priority: 3 Submitted By: David Hedley (davidhedley) Assigned to: Nobody (None) Summary: Add spaces to PDF file so reflow works.. Resolution: None Group: None Category: None Initial Comment: Current PDFs generated by pdfTex do not 'reflow' properly with Acrobat Reader - selecting 'reflow' causes all the words to run together. This appears to be because pdfTex uses explicit kerns for spaces instead of including the space character in the text string. Is it possible to change this? (perhaps by including a space in the text string and adjusting the explicit kern by the width of the space) ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2008-06-28 14:22 Message: patch 945 does this. Needs more testing. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=317&group_id=106

1 0

[pdftex-Feature Requests][718] Request of pdfsync
by pdftex-featurerequests＠sarovar.org 28 Jun '08

28 Jun '08

Feature Requests item #718, was opened at 2007-01-01 22:27 >Status: Closed Priority: 3 Submitted By: Juan Luis Varona (jlvm) Assigned to: The Thanh Han (hanthethanh) Summary: Request of pdfsync >Resolution: Accepted Group: None Category: None Initial Comment: The syncronization between the .tex and the .pdf files is veeeeeery useful. It is not necessary to explain it. Now, there are some tools to do it, but they are far of being good enough. For instance, pdfsync makes some work, but it has a lot of problems. Of instance, the output is different with or without pdfsync. I have read in TUGboat that, perhaps in the near future, pdfsync can be integrated en pdftex itself and improved. I request to do it as soon as possible. Yours sincerely, Juan L. Varona jvarona(a)unirioja.es ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2008-06-28 14:21 Message: synctex is in ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2007-09-30 21:28 Message: Logged In: YES user_id=4698 I have posted a patch that works for both dvi and pdf output mode. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-09-29 19:22 Message: Logged In: NO The output is also different with or without -src-specials in DVI mode. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-09-29 19:03 Message: Logged In: YES user_id=421 You didn't attach any file. :-{ Also please login before commenting. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-09-29 18:53 Message: Logged In: NO After some work with hanthethanh , here is a patch of pdftex 1.40.4 that would do the job reasonably well. The attached file is a zip archive containing the patch, a demonstration pdf output and some explanations. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-07-30 11:39 Message: Logged In: YES user_id=710 I am working on this, so I have assigned this item to myself. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-05-10 12:56 Message: Logged In: NO I second that strongly. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=718&group_id=106

1 0

[pdftex-Patches][871] Synchronization: pdfsync.sty embedded (1)
by pdftex-patches＠sarovar.org 28 Jun '08

28 Jun '08

Patches item #871, was opened at 2007-09-30 08:56 >Status: Closed Priority: 3 Submitted By: Jerome LAURENS (jlaurens) Assigned to: Martin Schröder (oneiros) Summary: Synchronization: pdfsync.sty embedded (1) Resolution: Accepted Group: v1.50.0 Category: User interaction Initial Comment: To the administrator, please remove the preceding patch submission The purpose is to implement some extensions very useful for synchronization, both forwards and backwards. Synchronization is the ability for a text editor and a pdf viewer to work together, displaying the same thing at the same time. For example, a text editor can ask a pdf viewer to display and outline the character in the output corresponding to the character under the cursor. Attached is a zip file containing diff against version 1.40.4, explanations and demonstrations in synchronize.readme/synchronize+frames.pdf PS: I have problems with my connection ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2008-01-29 09:40 Message: Logged In: NO The pdfsync package is a tremendous boost in the productivity for everyone that learns about it, specially when working with pdf files of more than a couple of pages. The synchronization between pdf viewer and tex editor is essential for keeping track of the changes you are doing without having to search over lots of .tex files or having to scroll over the entire pdf to find the relevant section. My work on latex is mainly done on Mac OS X using eclipse+texlipse+pdftex and the Skim PDF reader and with my discovery of pdfsync, the whole experience of writting latex documents have improved to the point i would not use anything else. So i would love to have this feature included as soon as possible so it can become a standard and avoid any package incompatibilities. Also, it is well known that the syncrhonization feature has been present a very long time for latex output to .dvi files and i think it is the time to bring this essential feature to the pdftex world to achieve the same level of functionality. Regards, Juan Ramón González, Granada, Spain ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2008-01-28 09:50 Message: Logged In: NO I understand the issue correctly, Laurens' suggested modification of pdftex would make synchronization a (potential) standard in all TeX installations and formats, without package incompatibilities. This should be regarded as an improvement over present implementations of this essential feature, at least essential for those who, like Schremmer, spend hours each day going back and forth between TeX source and pdf output. Please add it soon, Josep Maria Font Barcelona ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2008-01-26 05:23 Message: Logged In: NO As someone who spends hours everyday going back and forth between source and pdf with TeXShop under OSX 10.4.11, any improvement in the synchronization would be invaluable and so would Laurens's improvement. Regards --Schremmer ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2008-01-24 18:31 Message: Logged In: YES user_id=4698 Ok, I found some time to make the necessary corrections and improvements. The attached file contains explanations and examples about synchronization. The patch.diff file is the result of the "svn diff" command against the latest trunk (as of 01/24/08) Compared to the previous versions, the command line switch now works properly and there is now a mean to take into account the x and y offset that may be used by a postprocessor like dvipdf. Well, it is very difficult to find any kind of information/help about pdftex development, so please don't be too crude with me. ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2007-12-19 16:21 Message: Logged In: YES user_id=2217 Also, the command line switch seems to be broken. It only works with \synchronize=1 in the source here. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-18 14:50 Message: Logged In: YES user_id=421 Please update the patch against trunk and please use svn diff. I refuse to look at this patch more closely since the diff includes all the .svn files. ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2007-10-15 07:21 Message: Logged In: YES user_id=4698 Synchronize3.zip is available. It just adds a flag in the .sync file to indicate whether dvi or pdf mode was used. So far I have found only one problem, using dvips or dvipdf with a concrete offset (-x and -y options) will break the synchronization. If such a filter is gentle enough to indicate that it used a custom offset, then viewers can take this into account and the synchronization is not broken. Viewers will check the above mentionned flag to look for customized offset. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-09-30 22:00 Message: Logged In: YES user_id=421 You didn't attach Synchronize 2.zip yet... ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2007-09-30 21:10 Message: Logged In: YES user_id=4698 Synchronize 2.zip is a version extending the previous one. Now synchronization works the same for both dvi and pdf output modes. ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2007-09-30 21:09 Message: Logged In: YES user_id=4698 Synchronize 2.zip is a version extending the previous one. Now synchronization works the same for both dvi and pdf output modes. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=871&group_id=106

1 0

[pdftex-Patches][1812] Patch for bug report 1751
by pdftex-patches＠sarovar.org 28 Jun '08

28 Jun '08

Patches item #1812, was opened at 2008-06-24 22:29 >Status: Closed Priority: 3 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: The Thanh Han (hanthethanh) Summary: Patch for bug report 1751 Resolution: Accepted Group: v1.40.0 Category: PDF inclusion Initial Comment: Hello, this patch fixes bug report 1751 "bounding box ignored?". The source of the problem is pdftoepdf.cc: the contents stream is copied with *all* entries, but only Length, Filter, DecodeParms must be copied. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2008-06-28 14:15 Message: accepted since 1.40.8-rc2 ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2008-06-25 08:59 Message: Martin wrote: > While this probably works, I prefer a different > approach: Propagate all keys from the stream dict, > but check for name collisons. I disagree strongly: "Table 3.27 Entries in a page object" (latest doc for PDF 1.7) "Contents: stream or array A content stream describing the contents of this page" Only the stream data are of interest. Adding keys apart from generic stream keys (Filter, DecodeParms, Length, ...) into a dictionary of a probably different type is asking for trouble only without having any benefit. In contrary, the size of the PDF file increases. > Your patch limits us to some (already known) keys > and doesn't even handle all keys in table 3.4. > And who knows which keys will be added in > future PDF versions or if the PDF contains keys > with application data? "Be liberal in what you > accept." In this case bug reports are more likely and have happend already (bug #1751). Anyway, in case of future PDF versions you will not know, what you have to copy, too. Perhaps you also must add something to the Catalog or adding something in name trees, ... In case you expect some additions in the generic stream keys (Filter, ...), switch to variant A and wait for xpdf to implement this additions. (I haven't checked xpdf to handle external streams. In case it can handle them, variant A is better, because it supports this feature indirectly.) I had implented variant B for speed only, it avoids uncompressing and recompressing the stream data. > The input PDF in #1751 is broken. AFAIK no: | H.2 Feature Compatibility | Many PDF features are introduced simply by add | tionaries. Earlier versions of viewer applications | such entries and behave as if they were not there. | Such new features are therefore both forward- and | backward-compatible. Likewise, adding entries not | described in the PDF specification to dictionary | objects does not affect the viewers' behavior. Therefore it is even bug (#1751), if pdfTeX copies unknown entries. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-25 06:59 Message: While this probably works, I prefer a different approach: Propagate all keys from the stream dict, but check for name collisons. Not hard to do (just use an avl), but probably not worth it for pdfTeX anymore. But see http://tracker.luatex.org/view.php?id=56 Your patch limits us to some (already known) keys and doesn't even handle all keys in table 3.4. And who knows which keys will be added in future PDF versions or if the PDF contains keys with application data? "Be liberal in what you accept." The input PDF in #1751 is broken. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=1812&group_id=106

1 0

[pdftex-Patches][962] SyncTeX
by pdftex-patches＠sarovar.org 28 Jun '08

28 Jun '08

Patches item #962, was opened at 2008-05-20 16:01 >Status: Closed Priority: 3 Submitted By: Jerome LAURENS (jlaurens) Assigned to: Nobody (None) Summary: SyncTeX >Resolution: Accepted Group: v1.50.0 Category: User interaction Initial Comment: Dear all, SyncTeX design has changed. In order to add support in pdftex for the new design, we must clean the previous code from everything containing SyncTeX. Enclosed is a diff file against URL: svn://scm.foundry.supelec.fr/svn/pdftex/trunk Revision: 470 Everything concerning the old synctex design has been removed. The next step will be to add support for the latest design. It will be quite straightforward once the texlive repository is up to date. ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2008-05-22 19:45 Message: There was a mistake in the previous cleaning process that caused a segmentation fault. Curiously, it seemed to appear randomly. Anyway, with this patch, the diff between pdftex.web and the texlive version don't show anything related to synctex. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=962&group_id=106

1 0

[pdftex-Bugs][856] build.sh can't handle pathnames with spaces
by pdftex-bugs＠sarovar.org 28 Jun '08

28 Jun '08

Bugs item #856, was opened at 2007-08-14 07:48 >Status: Closed Priority: 1 Submitted By: Francky Leyn (leyn) Assigned to: Martin Schröder (oneiros) Summary: build.sh can't handle pathnames with spaces >Resolution: Rejected Group: v1.40.4 Category: Build process Initial Comment: Dear, I want to compile pdftex for cygwin. I untarred the distribution in /cygdrive/c/Document and Settings/Francky Leyn/My Documents/LaTeX leyn@newyork ~/LaTeX/pdftex-1.40.5 $ ./build.sh ... build.sh stops with the following error: configure: error: can not run /cygdrive/c/Documents and Settings/Francky Leyn/My Documents/LaTeX/pdftex- 1.40.5/build/../src/config/config.sub The file exists and is executable: $ ls -lh "/cygdrive/c/Documents and Settings/Francky Leyn/My Documents/LaTeX/pdftex- 1.40.5/build/../src/config/config.sub" -rwx------+ 1 leyn None 32K Jul 31 19:00 /cygdrive/c/Documents and Settings/Francky Leyn/My Documents/LaTeX/pdftex- 1.40.5/build/../src/config/config.sub The file /cygdrive/c/Documents doesn't exist of course and that is why buid.sh stops its execution. Could the scripts be modified so that they can handle spaces? Best regards, Francky Leyn ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-08-14 23:52 Message: Logged In: YES user_id=421 I'm sorry, but fixing this needs a change in the whole autofoo system of TL, which is not likely to happen soon. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-08-14 08:50 Message: Logged In: YES user_id=421 This needs a new configure script; I've pushed this upstream (to TeXlive). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=856&group_id=106

1 0

[pdftex-Bugs][935] The primitive \pdfstrcmp is not documented in the manuals
by pdftex-bugs＠sarovar.org 28 Jun '08

28 Jun '08

Bugs item #935, was opened at 2008-03-25 10:40 >Status: Closed Priority: 3 Submitted By: Ulrich Diez (ulrichdiez) Assigned to: Nobody (None) Summary: The primitive \pdfstrcmp is not documented in the manuals >Resolution: Accepted Group: None Category: None Initial Comment: The primitive \pdfstrcmp is documented neither in pdftex-syntax.txt, nor in "The pdfTeX manual (a4/letter/screen). (http://sarovar.org/docman/index.php?group_id=106&selected_doc_group_id=307&…) At comp.text.tex I was advised to send a bug-report. Ulrich ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2008-06-28 14:07 Message: documented since 1.30.0 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=935&group_id=106

1 0

[pdftex-Bugs][993] /Names array not sorted correctly
by pdftex-bugs＠sarovar.org 28 Jun '08

28 Jun '08

Bugs item #993, was opened at 2008-05-24 13:24 Status: Open Priority: 3 Submitted By: Martin Schröder (oneiros) Assigned to: The Thanh Han (hanthethanh) Summary: /Names array not sorted correctly >Resolution: Accepted Group: v1.40.6 Category: None Initial Comment: Axel Berger and Heiko Oberdiek report an error with the sorting of the /Names array: /Names [(cite.Kr07) 44 0 R (cite.Li08) 45 0 R (cite.M\37403) 23 0 R (cite.Mi00) 47 0 R (cite.Mi84) 48 0 R (cite.Mo04) 50 0 R] "cite.Mü03" (= "cite.M\37403") should come after "cite.Mo04". A test file with output is attached. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-05-27 16:48 Message: ok then this should be fixed as the spec says. BTW, it doesn't really solve the reported problem (ü will come after eg z). ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2008-05-27 16:03 Message: the spec says: The Names entries in the leaf (or root) nodes contain the tree’s keys and their associated values, arranged in key-value pairs and sorted lexically in ascending order by key. Shorter keys appear before longer ones beginning with the same byte sequence. The encoding of the keys is immaterial as long as it is self-consistent; keys are compared for equality on a simple byte-by-byte basis. so, it's just bytes ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-05-27 15:43 Message: this is a problem, but it's not clear to me how it should be fixed. Assume that we translate "\374" to the corresponding charcode (0374 = 252) before sorting, then how we decide the lexicographic order of that char? it can be intepreted as ü but also can be eg ytilde or something different, depending on the encoding we use. Comments? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=993&group_id=106

1 0