- ntg-pdftex - NTG Mailing Lists

Changing the pdfTeX banner for Debian-specific changes
by Frank Küster 24 Mar '06

24 Mar '06

Hi, this might already be resolved - we're still dealing with pdfTeX 1.21a in teTeX -, but also not, and therefore interest you. Julian Gilbey <jdg(a)polya.uklinux.net> wrote: >> >> as requested by Martin Schr?der, the pdfTeX maintainer, I'd like to add >> >> something about libpoppler to the "pdeftex --version" output or the >> >> general banner, but I don't manage. According to him, it should be >> >> sufficient to change texk/web2c/pdfetexdir/pdfetexextra.in, but that >> >> doesn't have any effect here - probably we have such an ancient version >> >> (1.20 instead of 1.40 in which he is thinking...). >> > >> > Just modifying the #define BANNER=... line in that file does it for >> > me. >> >> Strange - I tried and got funny results, e.g. after changing >> >> #define BANNER "This is pdfeTeX, Version 3.141592-PDFTEX-VERSION-ETEX-VERSION" >> >> to >> >> #define BANNER "This is not pdfeTeX, Version 3.141592-PDFTEX-VERSION-ETEX-VERSION" >> >> it printed "not pdfeTeX..." instead of "This is pdfeTeX..." > > With the normal version, compare: > > burnside:~ $ pdfetex --version > pdfeTeX 3.141592-1.21a-2.2 (Web2C 7.5.4) > kpathsea version 3.5.4 > Copyright (C) 1997-2004 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). > Kpathsea is copyright (C) 1997-2004 Free Software Foundation, Inc. > [...] > > with: > > burnside:~ $ pdfetex > This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) > ** > > It turns out that when producing the version string for --version in > lib/printversion.c, function printversionandexit, the leading prefix > "This is " is stripped off from the banner name. Furthermore, the > banner string is parsed like this: > > "This is pdfeTeX, Version 3.141592-PDFTEX-VERSION-ETEX-VERSION" > ^^^^^^^^------- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > stripped name progversion > > where "This is " is stripped, the prog name goes up to the first > comma, and the progversion is everything after the final space; then > the first line of the --version output is: > > name progversion (Web2C-version) Therefore it is indeed hard to add information about local changes, which naturally would be at the end (after an additional space). > So if all is wanted is to tweak the banner line, there are two ways to > do it: > > (1) Hackish: define BANNER to be something like: > "This is pdfeTeX with Debian tweaks, Version 3.141592-PDFTEX-VERSION-ETEX-VERSION" I'll go that way, but I'd appreciate if in future versions it would be possible to just add a "local_changes_remark" at an appropriate place (either the end of the line, or an additional line. > (2) Actually modify the printversionandexit code in lib/printversion.c > to output something like: > > string debianversion = "(Debian version blah)"; > > len = prog_name_end - banner - sizeof ("This is") + sizeof(debianversion); > prog_name = (string)xmalloc (len + 1); > strncpy (prog_name, banner + sizeof ("This is"), len); > prog_name[len] = 0; > > /* The Web2c version string starts with a space. */ > printf ("%s %s%s %s\n", prog_name, prog_version, versionstring, debianversion); > > and a similar change in one of the change files. > > But the latter seems like hard work :/ Should I open a feature request? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)

1 0

Creating identical PDF files with different pdfTeX runs
by Frank Küster 20 Mar '06

20 Mar '06

Hi, we (i.e. a couple of Debian developers, taking up old ideas of each individual and the tests in http://tug.org/svn/texlive/trunk/Master/support/tests/) are trying to implement some automated testing of pdf and dvi creation by pdftex. Possible applications are regression tests for the binary, for distributions (changed font setup etc.), or for package authors ("does the new version still cooperate with hyperref?"). For this, it would be great if it were possible to create identical pdf files in subsequent runs of pdfTeX. With \pdfinfo{/CreationDate (1980-09-09)} \year=1980 \month=9 \day=9 \time=10 \pdfcompresslevel0 I get pdf files that can be compared, but only after some grepping: egrep -a -v '/BaseFont|/FontName|/UniqueID|/ID|/CreationDate' $< > $@ With dvipdfmx (and perhaps with newer pdfTeX versions than the one in teTeX) /CMap or something like this needs to be excluded, too. Is it possible to achieve identical pdf files directly, by adding the proper commands, or would it be possible to add this feature? TIA, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)

8 24

/cwm
by Reinhard Kotucha 14 Mar '06

14 Mar '06

Hi, /cwm (compwordmark) in AGL or #200C in Unicode, see: http://www.unicode.org/charts (ZERO WIDTH NON JOINER) is a glyph with zero width which is intended to mark word boundaries. In German, the word "Auflage" should not contain an "fl"-ligature because it is composed from two words. There is a macro which allows for breaking such ligatures in german.sty and babel[german]. The glyph /cwm has never been used by TeX but Walter considers to make use of it in the future. The advantage would be that the behaviour of the TeX macro which breaks ligatures at word boundaries will depend on the font, while it is unaware of the font currently in use now. If I understood Walter correctly, he wants to add kerning at such word boundaries in a way that the amount of kerning depends on the current font. Currently the same amount of kerning is applied to all fonts. However, I'm sure that the glyph /cwm is missing in many fonts. On the other hand, if we need kerning, we do not need a special glyph from a font, create a virtual font with modified metrics, and so on. When we have OTF support some day, I assume that we need some new primitives anyway which support additional metrics derived from OTF files which are not supported by \fontdimen. As far as I can see, it's reasonable to add a new primitive so that you can write \font\myfont=xyz \myfont \compwordkern\font = .2em The TeX macro which breaks ligatures then can insert \compwordkern for the current font. This way we can have different kernings for different fonts and we are completey independ of the fonts we use. And, of course, I assume that microtype.sty will hide all the low-level stuff... Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------

2 3

DANTE 2006
by Reinhard Kotucha 13 Mar '06

13 Mar '06

Hi, for all of you who had not the opportunity to come to Berlin, here is a short summary of pdfTeX related talks. Till Tantau, the author of beamer, held a talk about TikZ (a frontend to pgf, the portable graphics format) which is a very powerful macro package to prepare inline graphics in latex/plain/context documents. Currently pgf does all calculations in tex, which is quite limited. He is looking forward to make use of LuaTeX in the future. He expects that trigonometric functions will be about hundred times faster then, and TikZ will be more powerful as it is today. Jonathan Kew gave an impressive demonstration of XeTeX. Though it runs on Mac OS/X systems at the moment only, he plans to port it to Linux and maybe Windows so that it can be part of TeXLive-2006. He said that both, XeTeX and pdfTeX, are moving targets at the moment, but he is thinking about merging them in the future. Yannis Haralambous held a talk with the title "Implementing OpenType and textemes into Omega". He already talked about it in Pont-a-Mousson, see: http://www.dante.de/dante/events/eurotex/papers/MOT02.pdf The good news is that he intends to present the pre-processor as a stand-alone program providing XML output at the EuroTeX 2006. Martin held a talk with the title "pdfTeX - gestern, heute, morgen" ("pdfTeX - yesterday, today, tomorrow") but I think there is no need to go into detail on this mailing list. Martin and Hartmut will hopefully tell you everything I forgot. Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------

2 1

Reminder: \pdfretval exists
by Martin Schröder 03 Mar '06

03 Mar '06

Hi, just a reminder: \pdfretval exists. Currently it's only used with \pdfobj useobjnum. I'm sure there are more uses. :-) Best Martin -- http://www.tm.oneiros.de

1 0

making links work in rotated text
by Vladimir Volovich 03 Mar '06

03 Mar '06

Hi! if i typeset e.g. a table in LaTeX's landscape environment, and there are some links in the table, they become not clickable because of rotation. it is a known problem, as far as i can tell (searching in google shows that; the reason seems to be that the clickable areas links remain where they were before the rotation, i.e. they are not affected by the rotation, unlike the text)... is there any hope that this problem is going to be solved in not too distant future? :) Best, v.

6 13

Re: [NTG-pdftex] [pdftex] pdftex, dvipdfmx, encguide
by Hartmut Henkel 28 Feb '06

28 Feb '06

On Tue, 28 Feb 2006, Hans Hagen wrote: > Werner LEMBERG wrote: > > > > I thought I'd pass on this recent note from Werner about pdftex > > > > generating a much larger file than dvipdfmx. [...] > > > > > > > thanks a lot. Very interesting! This was done with 1.21a, but even > > > the new 1.40.0-beta is not better. > > > > This is the very reason why pdftex is a bad choice for documents > > written in a CJK script. > > > indeed, although i remember that thanh looked into it (or was going to > look into it) > > it should be put high on the agenda it is there, now :-) The /Encoding in the embedded Type1 font file should be independent from an external encoding. Currently the external encoding is duplicated also in the font, unnecessarily, as this info is ignored anyway, due to the full external /Encoding. So we might have similar fonts in the PDF that differ only by their unused encodings. I believe we should keep the original /Encoding inside the font intact (unused anyway, only for information), using the value pairs coming with the font file. We can reduce the size of the /Encoding vector in the font so that only the entries of actually used glyphs are there. E. g. if an external /Encoding says 13 --> /foo and the internal original encoding says 55 --> /foo then if 13 --> /foo is typeset by pdftex, we need to lookup /foo in some hash or tree for the font file so we get the original 55 which goes into the subsetted font file stream. I'll try this. Then there is some magic needed to trigger glyph activation in one PFB file only... Regards, Hartmut

1 0

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

28 Feb '06

Patches item #438, was opened at 2005-10-16 21: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: Hans Hagen (hagen) Date: 2006-02-28 00: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 11: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-16 22: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-466 ] \primitive and \ifprimitive
by noreply＠sarovar.org 27 Feb '06

27 Feb '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.30.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. ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-14 08:17 Message: Logged In: YES user_id=3344 IMHO it would be better to rephrase the above to (and change the implementation accordingly :-(): <quote mode="changed"> \primitive is expandable, because it may asked to execute expandable primitives as well as unexpandable ones. \primitive<cs> will expand to one token, the original TeX primitive. This token will then be processed further as usual. </quote> If \primitive is left unexpandable, a lot of programming techniques seems to be unavailable, e.g., all redefined expandable primitives in expandable-only context. Or any assignment to the get the original primitive, like \edef\orignumber{\expandafter\noexpand\primitive\number} \expandafter\let\expandafter\orignumber\primitive\number Sidenote: The new \primitive seems to implement a subset of a full-blown namespace mechanism. If (pdf)TeX would have namespaces, one simply has to access the appropriate token within the "primitive" namespace (e.g. \primitive::number to access the original \number primitive, assuming the notation \<namespace>::<csname>). How about choosing an appropriate namespace mechanism for (pdf)TeX and implementing it instead? ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-02-13 18:56 Message: Logged In: YES user_id=1608 We need to think about this. I see your point, but making \primitive expandable forces the introduction of un-redefinable tokens, and that has its own problematic side-effects (like slowing down each and every definition). I welcome third opinions on whether the benefits outweigh that downside. At one point I tried making the expandability depend on the referred primitive, but that gave me headaches at the implementation stage (a pity, because that would have been nice). Yet another solution is to have an expandable command as well as an unexpandable command (two primitives instead of just the single \primitive). On the side note: I will happily write an implementation ... but only if someone comes up with a specification that works under all conditions instead of only under specific programming styles :-) ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-13 17:40 Message: Logged In: YES user_id=3344 IMHO it would be better to rephrase the above to (and change the implementation accordingly :-(): <quote mode="changed"> \primitive is expandable, because it may asked to execute expandable primitives as well as unexpandable ones. \primitive<cs> will expand to one token, the original TeX primitive. This token will then be processed further as usual. </quote> If \primitive is left unexpandable, a lot of programming techniques seems to be unavailable, e.g., all redefined expandable primitives in expandable-only context. Or any assignment to the get the original primitive, like \edef\orignumber{\expandafter\noexpand\primitive\number} \expandafter\let\expandafter\orignumber\primitive\number Sidenote: The new \primitive seems to implement a subset of a full-blown namespace mechanism. If (pdf)TeX would have namespaces, one simply has to access the appropriate token within the "primitive" namespace (e.g. \primitive::number to access the original \number primitive, assuming the notation \<namespace>::<csname>). How about choosing an appropriate namespace mechanism for (pdf)TeX and implementing it instead? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=466&group_id=106

1 0

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

27 Feb '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