July 2006 - ntg-pdftex - NTG Mailing Lists

[ pdftex-Patches-473 ] \ifabsnum and \ifabsdim
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Patches item #473, was opened at 2006-01-27 15:20 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=473&group_id=106 Category: Primitives Group: v1.30.0 >Status: Closed Resolution: Accepted Priority: 4 Submitted By: Taco Hoekwater (taco) Assigned to: Martin Schröder (oneiros) Summary: \ifabsnum and \ifabsdim Initial Comment: Here is a small change file that implements two new etex primitives : \ifabsnum \ifabsdim Usage is the same as \ifnum and \ifdim. The only difference is that they negate the values if they are negative before comparing. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 12:28 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2006-01-27 15:31 Message: Logged In: YES user_id=927 intended usage: \ifabsdim \dimexpr \maxheight - \currentheight \relax < .5pt assume that we're done \fi it can also be used to handle rounding errors when doing roundtrip calculations ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=473&group_id=106

1 0

[ pdftex-Patches-447 ] Don't write /Encoding for non-reencoded fonts
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Patches item #447, was opened at 2005-11-06 12:26 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=447&group_id=106 Category: Fonts Group: v1.30.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Taco Hoekwater (taco) Summary: Don't write /Encoding for non-reencoded fonts Initial Comment: The /Encoding entry in the /Font dictionary is only needed when the font is actually reencoded, see the PDF Ref. v. 1.6, section 5.5.5. Currently also for non-reencoded Type1 fonts the /Encoding entry and its /Encoding object with the /Differences array are generated from the /Encoding in the font, duplicating it unnecessarily. This happens particularily with the many CM fonts. By the tiny patch to writefont.c this /Encoding entry and the array object will not be generated and written any more for non-reencoded Type1 fonts. The PDF reader application will then take the /Encoding from the embedded font file. Testing welcome. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 12:27 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=447&group_id=106

1 0

[ pdftex-Patches-443 ] 512 zeros in Type1 fonts not copied anymore
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Patches item #443, was opened at 2005-10-24 22:41 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=443&group_id=106 Category: Fonts Group: v1.30.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Martin Schröder (oneiros) Summary: 512 zeros in Type1 fonts not copied anymore Initial Comment: When embedding Type1 fonts in PDF files, it is not needed to copy the trailing 512 zeros; they are redundant. This has been suggested in the paper "Two Diet Plans for Fat PDF" by Thomas A. Phelps and Robert Wilensky. Reduces file size a little. Then /Length3 = 0, see Table 5.24 in the PDF Ref. v. 1.6. The tiny patch to writet1.c does this for pdfTeX. No change in the dvips portion. In the patch also the font matrix transform is streamlined by use of generic transform macros. Testing welcome. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 12:27 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=443&group_id=106

1 0

[ pdftex-Patches-438 ] \pdfsavepos in DVI mode
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Patches item #438, was opened at 2005-10-16 23:52 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=438&group_id=106 Category: Positioning Group: v1.30.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Hartmut Henkel (hhenkel) Summary: \pdfsavepos in DVI mode Initial Comment: \pdfsavepos in DVI mode Hello, using \pdfsavepos in a package of mine (tabularht) I was wondering, why \pdfsavepos is not allowed to work in DVI mode. \pdfsavepos in PDF mode is based on cur_h and cur_v, both coming from the DVI frontend. The only difference I found is that the PDF format and pdfTeX's PDF mode know about page dimensions. Thus the directions of the axes are the same for the PDF format and the values of \pdfsavepos (\pdflastxpos, \pdflastypos). Origin: lower left corner horizontal axis: values increasing from left to right vertical axis: values increasing from bottom to top unit: sp The DVI case doesn't know about page dimensions, thus I suggest using cur_h=0 and cur_v=0 as origin. It is the left upper corner of the box that is being shipped out. Origin: left upper corner of the box horizontal axis: values increasing from left to right vertical axis: values increasing from bottom to top unit: sp Thus the absolute values differ in both modes and I don't see that this can be avoided. However, if the application uses a reference point then the relative values are exactly the same. The attachted patch enables and implements \pdfsavepos for the DVI mode. It also contains the patch for bug 437 (Two \immediate cancel themselves). Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 12:27 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2006-02-28 01:24 Message: Logged In: YES user_id=927 positioning has always been available in dvi mode as well by means of specials and postprocessing the dvi file (first by a script by taco, later by the dvipos program that comes with dvipdfmx); btw, when you mean 'the current drivers' you refer to latex, and you cannot assume that those are used outside latex, so that is no real reference -) in a similar fashion the dvipos functionality is no real reference either since it is mainly meant for appending info to the context second-pass-info file; anyhow, since pdftex is now the standard engine, there is no need to support the dvipos specials (apart from backward compatibility in context) because we had a "pos:papersize w h" special, dvipos could provide the same reference frame as when using the pdftex primitives; therefore, using the pdfpagewidth and pdfpageheight specification as in the suggested latest patch) is the best way to go (at least for context) (Since we now have pdfpagewidth/height in dvi mode, we get less and less \pdfprimitives that complain in dvi mode) Hans ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2005-10-17 13:39 Message: Logged In: YES user_id=1276 Hello, I have now extended the patch: \pdfpagewidth/height are now used for the page dimensions. Also the funny DVI origin offset of 1in is taken into account. Thus the values in DVI and PDF mode are the same. The exception is \pdf{h,v}origin. If the value is not 1in, then the values differ in DVI and PDF mode. However, also the DVI and PDF output will differ in this case. Thus the different values are then ok, I think. If someone wants to have the same values, he just sets \pdfpage{width,height} and let \pdf{h,v}origin untouched. Hartmut Henkel wrote: > to give page dimension info for pdftex also in > DVI mode, one could implement the standard > \special{papersize=x,y} also in pdftex (parallel > to \pdfpagewidth/height), so that it would be > scanned, and also go into the DVI file. Would > this help? I think, not really: * Scanning of \specials are done in PDF mode already, but here it is not really necessary, the current drivers know about \pdfpage{width,height}. * In DVI mode, the scanning of \special's contents must then be added to set \pdfpage{width,height}. But who needs this actually? * Relative positioning with \pdfsavepos works with or without the correct page size information. * Absolute positioning is more difficult in use (If you are somewhere in a box, how do you want to apply absolute positions?) * If someone insist on absolute positioning, he will probably not rely on an accidentally issued \special{papersize=...}. He will probably make sure, that the papersize information is set and then he can also set \pdfpage{width,height}. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> PS: The name of the patch file is now "v2-pdftex.ch.diff". And I have removed the patch of fixed bug 437. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-17 00:16 Message: Logged In: YES user_id=929 to give page dimension info for pdftex also in DVI mode, one could implement the standard \special{papersize=x,y} also in pdftex (parallel to \pdfpagewidth/height), so that it would be scanned, and also go into the DVI file. Would this help? Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=438&group_id=106

1 0

[ pdftex-Patches-434 ] Remove queued map item handling
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Patches item #434, was opened at 2005-10-13 01:08 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=434&group_id=106 Category: Fonts Group: v1.30.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Taco Hoekwater (taco) Summary: Remove queued map item handling Initial Comment: Remove queued map item handling from mapfile.c ============================================== Formerly all items from \pdfmapfile{+-=mapfile} or \pdfmapline{+-=mapline} were queued up in a list until the next font was selected; then the whole list was processed, e. g. all queued mapfiles or maplines read in. When one gave \pdfmapfile{mapfile} or \pdfmapline{mapline} without +-=, the pending list was cleared. The only practical use for this was to prevent reading in the default mapfile. But this can be done simpler, without queuing. With this patch all \pdfmapfile{+-=mapfile} or \pdfmapline{+-=mapline} requests are processed completely and immediately without queuing, which means that if e. g. a \pdfmapfile{+-=mapfile} primitive is scanned, the mapfile will be read in right away. This happens independently from selecting a font. When \pdfmapfile{+-=mapfile} or \pdfmapline{+-=mapline} is scanned, and there is a default mapfile, it is read first and then the mapfile. Reading of the default mapfile can be disabled by \pdfmapfile{} or \pdfmapline{} or \pdfmapfile{mapfile} or \pdfmapline{mapline} without +-= as long as the default mapfile hasn't already been read in. Latest when the first font is requested, the default mapfile will be read, if this hasn't already been disabled by the mentioned primitives. Apart from possibly reading the default mapfile, there is no other action when a font is requested, since the \pdfmapfile{+-=mapfile} or \pdfmapline{+-=mapline} primitives have already acted right away when they were called. The effects of this patch are the following: * Initial mapfile reading still can be blocked in the usual way. * The difficult to describe queuing mechanism has gone, code gets simpler. * Mapfile reading happens directly by the primitives. * Therefore it's possible to use \pdfretval with the primitives, to check success of the mapfile/line reading (not yet implemented). * As the return value is connected to the \pdfmapfile or \pdfmapline call, one can easier implement other map setting primitives and give them return values. This was not possible before, as the queuing was inbetween. * For any standard use, the patch should be compatible to the former queuing method. The mapfile.c is a patched version of the mapfile.c from Thanh's subfont patch pdftex-20050924.patch.gz for pdftex-1.30.3. Hope it doesn't sound too messy :-) For discussion. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 12:25 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=434&group_id=106

1 0

[ pdftex-Patches-416 ] new primitive pdflastlink
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Patches item #416, was opened at 2005-08-19 09:42 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=416&group_id=106 Category: Primitives Group: v1.30.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Ralf Utermann (ralfu) Assigned to: Hartmut Henkel (hhenkel) Summary: new primitive pdflastlink Initial Comment: This patch implements a new primitive \pdflastlink (analogous to \pdflastannot) which returns the object number of the last object created with \pdfstartlink. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 12:24 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=416&group_id=106

1 0

[ pdftex-Patches-386 ] grow obj_tab and dest_names arrays dynamically
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Patches item #386, was opened at 2005-07-10 20:29 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=386&group_id=106 Category: Memory allocation Group: v1.30.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hartmut Henkel (hhenkel) Summary: grow obj_tab and dest_names arrays dynamically Initial Comment: experimental patch to grow the obj_tab and dest_names arrays dynamically; arrays initially have 1000 entries. This required also update of file avlstuff.c. Similar to patch-366, which did this already for the pdf_mem array. Then all (?) pdftex-specific memory configuration parameters, obj_tab_size, dest_names_size, and pdf_mem_size in texmf.cnf would be ignored. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 12:23 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=386&group_id=106

1 0

[ pdftex-Patches-453 ] Object Streams for PDF-1.5
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Patches item #453, was opened at 2005-11-26 18:05 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=453&group_id=106 Category: Object Streams Group: v1.30.0 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Martin Schröder (oneiros) Summary: Object Streams for PDF-1.5 Initial Comment: Rough early patch, work in progress, produces PDF-1.5 object streams and cross reference streams. With the patch, and enabled by \pdfminorversion=5, and with luck, pdfetex produces e. g. from its WEB source a PDF file with size 5.97 MByte instead of 11.2 MByte without object streams. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 12:23 Message: Logged In: YES user_id=421 This has been included in version 1.40 ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-01-07 01:06 Message: Logged In: YES user_id=929 objstream.ch updated: 1. object stream statistics added. 2. maximum allocation values are added in brackets. Example: PDF statistics: 630 PDF objects out of 1000 (max. 8388607) 577 compressed objects within 6 object streams 113 named destinations out of 1000 (max. 131072) 8353 words of extra memory for PDF output out of 10000 (max. 10000000) Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-12-26 20:21 Message: Logged In: YES user_id=929 Patch update. Object stream writing is now controlled by primitive \pdfobjcompresslevel = 0...3 (/pdfobjectstreams primitive removed). 0 = no object streams at all, 1 = compress objects excluding the ones from embedded PDF files (for handling of problematic PDF files) and /Info dictionary (for legibility), 2 = also compress objects from embedded PDF files, but leave /Info uncompressed, 3 = compress everything. Testing welcome. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=453&group_id=106

1 0

[ pdftex-Bugs-393 ] Ensure newline before endstream
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Bugs item #393, was opened at 2005-07-25 16:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=393&group_id=106 Category: None Group: v1.30.0 >Status: Closed >Resolution: Fixed Priority: 2 Submitted By: Martin Schröder (oneiros) Assigned to: Martin Schröder (oneiros) Summary: Ensure newline before endstream Initial Comment: As reported by Hans, there is not always a newline before endstream, although the PDF reference recommends it. Any change needs careful testing. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 12:20 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-01-06 23:45 Message: Logged In: YES user_id=929 Implementation of pdf_end_stream() changed: Last byte within any stream written to the PDF file is now remembered in pdf_last_byte, so that one can check if a separate pdf_new_line_char "\n" is needed before "endstream". No need to look back in maybe already flushed pdfbuf. Patch to 1.40.0-alpha-20060106. Plus a few tiny patches. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=393&group_id=106

1 0

[ pdftex-Bugs-509 ] invalid pdf created if font name contains space
by noreply＠sarovar.org 26 Jul '06

26 Jul '06

Bugs item #509, was opened at 2006-04-13 20:37 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=509&group_id=106 Category: Fonts Group: v1.40.0 >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Tom Bishop (tbishop) Assigned to: Hartmut Henkel (hhenkel) Summary: invalid pdf created if font name contains space Initial Comment: pdftex 3.141592-1.30.4-2.2 runs the following code without complaining: \pdfmapline{+mssong4e <mssong.ttf <mssong4e.enc} \font\testfont=mssong4e at 20pt \testfont\char"00 \bye -- but the resulting pdf file can't be opened by Adobe Reader or GhostScript. GhostScript reports "Unknown operator: Song". The pdf file includes "/BaseFont /FEVAQU+MS Song". Evidently, the problem is the space in "MS Song", because if I use a hex editor to replace the space with an underscore, then the pdf becomes OK. The same font worked fine with earlier pdftex versions. It's a Chinese Unicode TrueType font, from Microsoft. I haven't tried installing pdftex 1.30.6; is it possible that would fix the problem? I just re-installed TeX using i-Installer for Mac OS X; it still uses pdftex 1.30.4. Here is the output of pdftex when running the test file: This is pdfeTeX, Version 3.141592-1.30.4-2.2 (Web2C 7.5.5) entering extended mode (./test3.tex [1{/Users/tbishop/Library/texmf/fonts/map/pdftex/ updmap/pdftex.map }] )</usr/local/teTeX/share/texmf.tetex/fonts/type1/bluesky/cm/ cmr10.pfb>{/usr/ local/teTeX/share/texmf.local/fonts/enc/pdftex/enc/mssong4e.enc} </usr/local/teT eX/share/texmf.local/fonts/truetype/mssong.ttf> Output written on test3.pdf (1 page, 5067 bytes). Transcript written on test3.log. Thanks in advance for any help! Best wishes, Tom Bishop (wenlin(a)wenlin.com) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-26 12:19 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-04-14 00:16 Message: Logged In: YES user_id=929 well, the PDF ref. says to strip the spaces, and i don't know what consequences such underscores would have. So it seems that just stripping spaces might be a little bit closer to the right thing (in the view that this is only with buggy fonts anyway). ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2006-04-13 23:58 Message: Logged In: YES user_id=927 why not replace spaces by underscore (just as a precaution) ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-04-13 23:25 Message: Logged In: YES user_id=929 patch makes pdftex lenient with (buggy) TTF fonts that have spaces in PostScript name, strips spaces in /BaseFont and /FontName, e. g.: "MS Song" ---> "MSSong" ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-04-13 22:54 Message: Logged In: YES user_id=929 ah, after the PDF reference 5. ed. page 388 in case there would be no PostScript name entry we could be cruesome and strip the blank. But there is a wrong PostScript name in the font. So maybe one could flag a warning (or not?) and just strip the blank? (which would be easy) Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-04-13 22:39 Message: Logged In: YES user_id=929 This mssong.ttf version seems to be buggy. Here is a diagnostic printout from function ttf_read_name() in writettf.c; these are all available entries from the "Naming Table": i=0 platform_id=1 encoding_id=0 name_id=0 name <(c) Copyright ZHUHAI Stone Computerized typesetting system R&D LTD., 1995-1996> i=1 platform_id=1 encoding_id=0 name_id=1 name <MS Song> i=2 platform_id=1 encoding_id=0 name_id=2 name <Regular> i=3 platform_id=1 encoding_id=0 name_id=3 name <Microsoft:MS Song:1996> i=4 platform_id=1 encoding_id=0 name_id=4 name <MS Song> i=5 platform_id=1 encoding_id=0 name_id=5 name <Version 1.00> i=6 platform_id=1 encoding_id=0 name_id=6 name <MS Song> ---> ttf_read_name <MS Song> There is no usable PostScript name in: The TTF standard tells that under name_id=6 there should be the Postscript font, but here it is "MS Song" with a blank. As long as the font does not contain a valid PostScript name, i have no idea how to tweak this correctly... Other clues anybody? Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=509&group_id=106

1 0