- ntg-pdftex - NTG Mailing Lists

[ pdftex-Patches-469 ] \currentexpansionmode + \ifalignscanning - \ifinedef
by noreply＠sarovar.org 17 Jan '06

17 Jan '06

Patches item #469, was opened at 2006-01-12 02:39 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=469&group_id=106 >Category: Primitives Group: None Status: Open >Resolution: Postponed Priority: 5 Submitted By: Morten Høgholm (morten) >Assigned to: The Thanh Han (hanthethanh) Summary: \currentexpansionmode + \ifalignscanning - \ifinedef Initial Comment: Here's a patch made against pdftex-1.40.0-alpha-20060111. It removes the \ifinedef primitive for a different primitive, namely \currentexpansionmode. This read-only register is 0 when doing regular typesetting, 1 when inside \edef or \xdef and 2 in other cases of full expansion with scan_toks. It could possibly be extended to distinguish between \marks and \write etc. Comments more than welcome on this one! I have also added an \ifalignscanning test. It is true whenever TeX is looking for \noalign etc. so is most useful for a \stopalignscanning function defined as \def\stopalignscanning{\ifalignscanning\relax\fi} ---------------------------------------------------------------------- Comment By: Morten Høgholm (morten) Date: 2006-01-16 21:23 Message: Logged In: YES user_id=3333 @None: An \ifalignscanning primitive can also help macros like LaTeX's \multicolumn and other code that relies on seeing \noalign or \omit to recover gracefully with a comprehensible error message. ---------------------------------------------------------------------- Comment By: Morten Høgholm (morten) Date: 2006-01-13 05:50 Message: Logged In: YES user_id=3333 Yes, just ideas here, which is why I asked for comments. We can discuss this on the list (once my subscription is accepted). ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-01-12 11:22 Message: Logged In: YES user_id=1608 Like Hans, I also prefer separate if primitives, mainly because I do not want to have to remember the meanings of the possible integer values (for that reason, I'm not too happy about \currentgrouptype either). Taco ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-01-12 10:14 Message: Logged In: NO i wonder why we need \ifalignscanning or \stopalignscanner at all when eTeX already has this feature - any \protected macro stops the scanning. ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2006-01-12 09:08 Message: Logged In: YES user_id=927 somehow i think that if's are a better idea than a register because in your case the register only registers one case at the same time (when i saw this patch the first time, i wondered why not a complete set was implemented) - ifincsname - ifinedef - ifinwrite - ifinspecial - ifinpdfliteral - ifinannotbody - ifinmessage (special case of write) - ifinalign - ifinmark probably some more (ok, normally all those conditions can comfortably be catched in a macro package but if we add them, we should be complete in addition to this there can be a register which keeps track of the innermost one (we can have ifcsname inside an edef inside an align concerning the \stopalignscanner i think it's better to have something primitive like \crcr, say \endalign because using if's can have its own problem (we should not worry to much about a name clash, since one can always let it to another one); so, we should wait with adding this patches till (1) we agree and (2) it is complete remark: also, it's dangerous to add patched before a decent decission/interface is dediced upon; once it's in, we cannot change it any more Hans ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=469&group_id=106

1 0

[ pdftex-Patches-466 ] \primitive and \ifprimitive
by noreply＠sarovar.org 17 Jan '06

17 Jan '06

Patches item #466, was opened at 2006-01-07 17:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=466&group_id=106 Category: Primitives Group: v1.40.0 Status: Open >Resolution: Accepted Priority: 4 Submitted By: Taco Hoekwater (taco) Assigned to: Martin Schröder (oneiros) Summary: \primitive and \ifprimitive Initial Comment: This patch implements two new primitives: \primitive \par This will run the 'primitive' command \par, even if it has been re- or undefined in the meantime. \primitive is not expandable, because it may be asked to execute unexpandable primitives as well as expandable ones. If you supply a nonexistant primitive, it will be ignored (no error is raised). The second primitive is a new type of \if: \ifprimitive \par ... \else .. \fi returns true if the current meaning of \par is the 'primitive' command \par. The patch is against alpha-20051226, i hope that is not too old (?). I expect to do at least one minor update during the beta cycle, after the pdftex code is flattened. It was quite a struggle to make this change file work ok, and as a result, there are a few ugly web hacks. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=466&group_id=106

1 0

[ pdftex-Patches-462 ] HZ font expansion by text matrix manipulation
by noreply＠sarovar.org 17 Jan '06

17 Jan '06

Patches item #462, was opened at 2005-12-23 23:35 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=462&group_id=106 Category: Positioning Group: v1.40.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) >Assigned to: The Thanh Han (hanthethanh) Summary: HZ font expansion by text matrix manipulation Initial Comment: Use textmatrix Tm instead of /FontMatrix for font expansion. Then a font file will be embedded only once for all expansion factors. Gives smaller PDF files. Works then also for non-embedded fonts. TrueType not tried yet. Rough patch only, incomplete, work in progress, no warranty, not for production. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=462&group_id=106

1 0

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

17 Jan '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: Open >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: 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-Patches-447 ] Don't write /Encoding for non-reencoded fonts
by noreply＠sarovar.org 17 Jan '06

17 Jan '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: Open >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 ---------------------------------------------------------------------- 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 17 Jan '06

17 Jan '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: Open >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 ---------------------------------------------------------------------- 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 17 Jan '06

17 Jan '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: Open >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: 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 17 Jan '06

17 Jan '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: Open >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 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=434&group_id=106

1 0

[ pdftex-Patches-432 ] Rules in a PDF qQ group
by noreply＠sarovar.org 17 Jan '06

17 Jan '06

Patches item #432, was opened at 2005-10-06 21:01 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=432&group_id=106 Category: Positioning >Group: v1.30.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) >Assigned to: Hans Hagen (hagen) Summary: Rules in a PDF qQ group Initial Comment: Put rules with their positioning on the page inside a qQ group. Should make \pdfliteral page {...} behave consistently after text or rules or images, as then any positioning starts from the PDF origin; no delta-positioning anymore. It's already being tested in pdfluatex. Just to have it at sarovar... Testing welcome, particularily with text and graphics transforms by graphicx package, to spot backward incompatibilities, if any... Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-09 15:07 Message: Logged In: YES user_id=929 Update pdf_set_origin_temp: Now has (h, v) parameters. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=432&group_id=106

1 0

[ pdftex-Patches-427 ] Character positioning patch
by noreply＠sarovar.org 17 Jan '06

17 Jan '06

Patches item #427, was opened at 2005-09-11 12:39 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=427&group_id=106 Category: Positioning >Group: v1.30.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) >Assigned to: Hans Hagen (hagen) Summary: Character positioning patch Initial Comment: Experimental patch increases resolution of /Widths array by 1 fractional digit, makes corrections of type ")-1(" and ")1(" in the TJ array happen much less often, particularily for CM fonts. Gives e. g. 1 % PDF file size shrink for pdfetex web sources compiled into PDF. Rough patch only, not for production. Testing welcome. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-09 15:06 Message: Logged In: YES user_id=929 Patch extended: Now pdf_set_origin has (h, v) parameters, simplifies pdf_begin_text procedure. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-09 00:25 Message: Logged In: YES user_id=929 Removed pdf_first_space_corr variable, as it seems that it was defunct anyway: There was no pdf_end_string procedure call (only place where something is done with pdf_first_space_corr), where afterwards the pdf_h variable (then modified by pdf_first_space_corr) would actually be used. E. g. pdf_moveto uses pdf_last_h instead, and after pdf_end_text there is anyway a pdf_set_origin call. And pdf_begin_string gets simpler. Testing welcome! Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-03 01:16 Message: Logged In: YES user_id=929 patch updated: now the TJ array building in procedure pdf_begin_string is simplified/tidied up. Testing welcome! Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=427&group_id=106

1 0