- ntg-pdftex - NTG Mailing Lists

Re: [NTG-pdftex] Possible bug in pdfetexk (re \hoffset)?
by Heiko Oberdiek 28 Jan '06

28 Jan '06

On Fri, Jan 27, 2006 at 06:17:16PM +0000, Philip TAYLOR wrote: > Dear all -- The following preamble produces a correctly > centered letter using TeX, but PdfTeX appears to offset > everything by about 1,5 em (see commented-out \advance > at-end). A sample document follows. > > Philip Taylor > -------- > % letter-macros > > \def \from {\leftskip = 0 pt plus 1 fill \parskip = 0 ex \obeylines} > \def \to {\rightskip = 0 pt plus 1 fill \parskip = 0 ex \obeylines} > \def \body {} > \def \blockquote {\vskip \parskip \leftskip = 3 em \rightskip = 0 ex > plus 1 fill \parskip = 0 ex \obeylines} > \def \signature {\vskip 3\parskip} > % pdfTeX also knows \pdfhorigin and \pdfvorigin % In my teTeX installation the values are set during generating % the format files in pdftexconfig.tex: % \pdfhorigin=1 true in % \pdfvorigin=1 true in % \showthe\pdfhorigin = 72.26999pt > \magnification \magstep 1 % Now the values of \pdfhorigin, pdfvorigin need to be % reassigned, see below > \parindent = 0 em > \parskip = 3 ex > > \hsize = 210 true mm > \vsize = 297 true mm > \input ifpdf.sty % it sets \ifpdf for detecting pdfTeX in pdf mode > \begingroup > \hoffset= 1 true in > \voffset = 1 true in > \globaldefs = 1 \ifpdf \pdfhorigin = 1 true in \pdfvorigin = 1 true in % now the value is 60.22462pt (same as \hoffset = 1 true in). > \pdfpagewidth = \hsize > \pdfpageheight = \vsize \fi > \advance \hsize by -2\hoffset > \advance \vsize by -2\voffset > \endgroup Yours sincerely Heiko <oberdiek(a)uni-freiburg.de>

2 2

Re: [NTG-pdftex] [tex-live] Re: Possible bug in pdfetexk (re \hoffset)?
by Martin Schröder 27 Jan '06

27 Jan '06

On 2006-01-27 21:38:02 +0100, Lars Madsen wrote: > This is actually rather interesting, I had a user who came and complained > about this very thing, pdftex producing different margins than TeX. > > When has this changed? I don't use plain TeX or pdfTeX myself so I haven't > noticed. The user in question claims that his document worked fine under > both systems in TL 2004. 1.20a corrected this. See the thread at http://www.ntg.nl/pipermail/ntg-pdftex/2004-April/000485.html Best Martin -- http://www.tm.oneiros.de

1 0

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

27 Jan '06

Patches item #473, was opened at 2006-01-27 14:20 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=473&group_id=106 Category: Primitives Group: None Status: Open Resolution: None Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Nobody (None) 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: Hans Hagen (hagen) Date: 2006-01-27 14: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-473 ] \ifabsnum and \ifabsdim
by noreply＠sarovar.org 27 Jan '06

27 Jan '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: None Status: Open Resolution: None Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Nobody (None) 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. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=473&group_id=106

1 0

1.40.0-beta-20060124
by Martin Schröder 26 Jan '06

26 Jan '06

http://sarovar.org/download.php/902/pdftex-1.40.0-beta-20060124.tar.bz2 - pdfTeX now includes pdfeTeX, i.e. there is no way to make a binary without eTeX support. Also the sources of TeX, eTeX and pdfTeX have been merged into one file pdftex.web - most pdfTeX change files are gone; only one file (pdftex.ch) remains. - improved patches: - 393 Ensure newline before endstream Have fun Martin -- http://www.tm.oneiros.de

4 6

1.40.0-beta-20060125
by Martin Schröder 25 Jan '06

25 Jan '06

http://sarovar.org/download.php/903/pdftex-1.40.0-beta-20060125.tar.bz2 [this is the same as 1.40.0-beta-20060124, but it works] - pdfTeX now includes pdfeTeX, i.e. there is no way to make a binary without eTeX support. Also the sources of TeX, eTeX and pdfTeX have been merged into one file pdftex.web - most pdfTeX change files are gone; only one file (pdftex.ch) remains. - improved patches: - 393 Ensure newline before endstream Have fun Martin -- http://www.tm.oneiros.de

1 0

pdftex and xpdf (and its security bugs): What about a libxpdf?
by frank＠kuesterei.ch 24 Jan '06

24 Jan '06

Dear pdftex developers, during the last months security support for software containing xpdf code was a nightmare - not only that there were many security issues discovered, moreover everybody used a different patch, it was unclear to what extent older versions were affected, and so forth. This was also a problem for us, the teTeX maintainer in Debian, which currently has three versions of pdftex with three different versions of the xpdf code. What would you think about creating a shared library, "libxpdf", and using that for pdftex, either linked dynamically (for Linux/Unix distributions) or statically (for TeX-live and friends)? There is already such a library, libpoppler, a fork of the xpdf code (http://poppler.freedesktop.org/) However, I do not know whether the xpdf author, Derek B. Noonburg, is generally unwilling to create a shared library, or whether people simply didn't ask him. Personally I would prefer to have as little a number of versions of the same code, and thus to get a shared library from xpdf proper. If you agree, I would be oblidged if one of you would contact Derek Noonburg (derekn(a)foolabs.com) and ask him. He seems to be a little unresponsive at times, and has not answered a similar question from the maintainer of the xpdf package in Debian for a couple of weeks now. Maybe we can convince him that this is a good idea if he is approached from different sides. Alternatively, if he is unwilling to make this change, do you think using libpoppler would be feasible? Many thanks in advance, Frank Küster -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer

2 3

Re: [NTG-pdftex] Flattening the web files
by Thanh Han The 21 Jan '06

21 Jan '06

On Wed, Jan 18, 2006 at 12:48:26AM +0100, Staszek Wawrykiewicz wrote: > On Tue, 17 Jan 2006, Hans Hagen wrote: > > > >But the name of the project will still be pdfTeX (not pdfeTeX), right? > > Good decission. > > > indeed, let's stay with the historic name (of course it's up to thanh to > > make the final decission on that); > > Sure. Thanh, would you please say the final agreement that pdftex means > from now "pdftex with all etex extensions"? (no more pdfetex) yes I agree (sorry for the delay :). So pdftex now is "pdftex + etex + further extensions made or accepted by pdftex team". Regards, Thanh

1 0

1.40.0-beta-20060117
by Martin Schröder 18 Jan '06

18 Jan '06

http://sarovar.org/download.php/898/pdftex-1.40.0-beta-20060117.tar.bz2 - pdfTeX is now pdfeTeX, i.e. there is no way to make a binary without eTeX support. Also the sources of TeX, eTeX and pdfTeX have been merged into one file pdfetex.web - strip trailing zeros in fractions of reals written - removed patch 467 \ifindef - improved logging of objstreams Have fun Martin -- http://www.tm.oneiros.de

3 4

[ 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 01: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: Hans Hagen (hagen) Date: 2006-01-17 22:22 Message: Logged In: YES user_id=927 concerning alignments: - how about adding \everyaligncell (in addition to \everycr) - how about the other iftests? - (and \nospan -) ---------------------------------------------------------------------- Comment By: Morten Høgholm (morten) Date: 2006-01-16 20: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 04: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 10: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 09: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 08: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-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

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

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

1 0

[ pdftex-Patches-415 ] various extensions and fixes
by noreply＠sarovar.org 17 Jan '06

17 Jan '06

Patches item #415, was opened at 2005-08-19 09:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=415&group_id=106 Category: Primitives Group: v1.30.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Martin Schröder (oneiros) Summary: various extensions and fixes Initial Comment: This is a patch for various experimental extensions: - \pdfinsertht: return the height of an insert (requested by Hans); this has similar syntax to \pdftexrevision. - do not fail when \pdfobj is used with an invalid object number (requested by Hans) - snapping: support for grid typesetting -- see snap.txt for details - kern before space: allow changing interword glues in a flexible way and inserting a kern before certain characters -- see kern-before-interword-glue.txt for details The notes in snap.txt and kern-before-interword-glue.txt are from email correspondence with people interested in; hence these notes are somewhat informal, inaccurate or out-of-date. How to apply: ~~~~~~~~~~~~~ cd /path/to/pdftex-1.30.0-srcdir/src/texk patch -p1 < /path/to/pdftex-20050818.patch cd web2c make pdfetex ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-09-04 18:22 Message: Logged In: YES user_id=421 The patch for invalid object numbers is included in 1.30.1++ ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=415&group_id=106

1 0

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

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

1 0

[ pdftex-Patches-467 ] new primitive \ifinedef
by noreply＠sarovar.org 17 Jan '06

17 Jan '06

Patches item #467, was opened at 2006-01-10 05:32 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=467&group_id=106 >Category: Primitives >Group: v1.40.0 >Status: Closed >Resolution: Rejected >Priority: 3 Submitted By: The Thanh Han (hanthethanh) >Assigned to: The Thanh Han (hanthethanh) Summary: new primitive \ifinedef Initial Comment: This patch (by Morten Høgholm) contains improvement for the \ifincsname primitive and implements a new similar primitive \ifinedef. Made against pdftex-1.40.0-alpha-20060106 ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-01-17 22:52 Message: Logged In: YES user_id=421 Needs further discussion. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=467&group_id=106

1 0

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

16 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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Morten Høgholm (morten) Assigned to: Nobody (None) 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