- ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-484 ] extra kerning inhibits hyphenation
by noreply＠sarovar.org 01 Nov '06

01 Nov '06

Bugs item #484, was opened at 2006-02-13 19:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=484&group_id=106 Category: hz Group: v1.40.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: extra kerning inhibits hyphenation Initial Comment: Hyphenation will be inhibited by appended or prepended kerns: \showhyphens{pdftex} { \pdfprependkern=1 \knbccode\font`e=100 \showhyphens{pdftex} } { \pdfappendkern=1 \knaccode\font`e=100 \showhyphens{pdftex} } \bye (In a milder mood, I would have filed this as a feature request, not as a bug report. But I do think that it's a major drawback, which renders this new extension useless for a lot of applications.) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-11-01 18:38 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=484&group_id=106

1 0

[ pdftex-Patches-663 ] fix for bugs #481--483
by noreply＠sarovar.org 01 Nov '06

01 Nov '06

Patches item #663, was opened at 2006-10-21 14:29 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=663&group_id=106 Category: hz Group: v1.40.0 Status: Closed Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: fix for bugs #481--483 Initial Comment: This is an attempt to fix bug #481--483 - This patch applies to the pristine pdftex-1.40.0-beta-20061017 sources only; if you have applied another patch(es) to the sources, please discard them and start from the fresh ones. - How to apply: ,-------- | cd /path/to/pdftex-1.40.0-beta-20061017/src | cat /path/to/the/patch | patch -p1 | ./configure | cd texk/web2c | make pdftex `-------- ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-11-01 18:37 Message: Logged In: YES user_id=421 Thanh, I looked at it, and as it does what you claim (fix #481-484) and doesn't seem to brake anything, it's in. :-) Although I'd like Hartmut to also have a look at it. hz isn't exactly my specialty. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-28 18:01 Message: Logged In: YES user_id=710 Martin, have you looked at this patch? What do you think of it? ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-22 23:38 Message: Logged In: YES user_id=710 This is an update of the previous patch, which attemps to solve problem #484 as well (I would not call #484 a bug but a limitation -- a bug would mean that the behaviour is inconsistent with the specification). This patch is *very different* from the previous one, since now kerns inserted by the new primitives are treated as implicit kerns (they were treated as explicit kerns before this patch). This can lead to a very different behaviour, so be prepared :) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-10-21 15:54 Message: Logged In: YES user_id=421 Thanks! Any idea for 484? :-) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=663&group_id=106

1 0

xpdf/poppler usage: Movements on the poppler side, and a request for help
by Frank Küster 28 Oct '06

28 Oct '06

Dear all, recently more projects that do not need any of the fancy graphical interfaces are considering using poppler, e.g. CUPS. However, the poppler developers plan to make unavailable the old, undocumented, never planned and unmaintainable API of "plain libpoppler". These two wishes together give us a fair chance that someone will actually do the work and develop a clean API for a plain C-only poppler, without any graphics payload. Therefore it would be nice if someone among the pdfTeX developers would take part in the discussion, in particular help answer the question in http://lists.freedesktop.org/archives/poppler/2006-October/002260.html ,---- | What functionality would the tetex people need exported from such an | API? `---- At a short glance over pdftoepdf.cc and pdftosrc.cc, I only found these symbols: Ref GfxFont GBool PDFDoc GString LinkDest Stream But in fact there may be more - and you may also have some wishes about PDF parsing and manipulation that need to be added yet. Is there anyone who would take up this task? TIA, Frank P.S. For those who don't remember what this is about: The frequent security bugs in xpdf code, sometimes exploitable with hand-crafted pdf files, are considered to be also a security problem in pdfTeX and other software that embeds such code, by the security teams of different Linux distributions. And it causes major headaches, since each embedded xpdf version needs a slightly changed patch. The goal is to replace the xpdf code with a poppler copy, so that static linking would still be possible, but distributions could also link dynamically and fix security problems with just one new package for libpoppler. -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)

5 11

[ pdftex-Patches-663 ] fix for bugs #481--483
by noreply＠sarovar.org 28 Oct '06

28 Oct '06

Patches item #663, was opened at 2006-10-21 12:29 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=663&group_id=106 Category: hz Group: v1.40.0 Status: Closed Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hartmut Henkel (hhenkel) Summary: fix for bugs #481--483 Initial Comment: This is an attempt to fix bug #481--483 - This patch applies to the pristine pdftex-1.40.0-beta-20061017 sources only; if you have applied another patch(es) to the sources, please discard them and start from the fresh ones. - How to apply: ,-------- | cd /path/to/pdftex-1.40.0-beta-20061017/src | cat /path/to/the/patch | patch -p1 | ./configure | cd texk/web2c | make pdftex `-------- ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2006-10-28 16:01 Message: Logged In: YES user_id=710 Martin, have you looked at this patch? What do you think of it? ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-22 21:38 Message: Logged In: YES user_id=710 This is an update of the previous patch, which attemps to solve problem #484 as well (I would not call #484 a bug but a limitation -- a bug would mean that the behaviour is inconsistent with the specification). This patch is *very different* from the previous one, since now kerns inserted by the new primitives are treated as implicit kerns (they were treated as explicit kerns before this patch). This can lead to a very different behaviour, so be prepared :) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-10-21 13:54 Message: Logged In: YES user_id=421 Thanks! Any idea for 484? :-) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=663&group_id=106

1 0

Adding a \cscode
by Javier Múgica de Rivera 25 Oct '06

25 Oct '06

This is a copy of a message I sent to the Latex3 list some time before and I got no answer (something not rare in that list). So I post it here, where it also belongs. There have been in the past many discussions about how to create a really multilingual program. One of the points was to allow typeseting control sequences (cs) in Russian (say), but we cannot simply make the \catcode equal to 11 because then the character would be transparently passed to the dvi (ie., the font), which only works if input and output encondings match. Can we simply add in pdftex a \cscode? Such a \cscode would be equal to 1 or 0, accordingly to whether the characert is allowed in the name of a cs or not (more precisely, a character with \cscode 0 would make the previous one the last of the cs, or if it is the first one it would be the only one in the name of the cs). In Latex, the setting of the cscodes would be done when selecting the input encoding. In order not to break tons of existing code, we should still allow catcode 11 characters to form control names. Thus, whenever now we have (approximately, I have not yet read the sources) if(catcode=11) we change it with if(catcode=11 or cscode=1) %If cscode=1 then, even if catcode=active, the character works as a letter when building the name of a control word We initialy set all cscodes equal to 0, so for the existing code nothing changes, while form now on we will be able to type control sequences with our alphabet (cyrilic, greek, ...), even if those characters are active ones. -- Javier A.

3 4

pdftex in dvi mode and reading JPEG files
by Eric.Brunet＠lps.ens.fr 25 Oct '06

25 Oct '06

Hi, I have always found annoying that pdftex and latex don't accept the same formats of image files (jpg,png,pdf versus eps). It doesn't really make sense, as including a JPEG into a postscript file is a very easy operation since postscript 2.0. It annoys me so much that I am trying to change that. So far, I have written a patch for dvips (the version in the texlive) which makes dvips able to read and embed JPEG files into a postscript. The next step is adding LaTeX support. As it stands, one can use my patched dvips with a LaTeX file looking like ... \usepackage{graphicx} \DeclareGraphicsRule{.jpg}{eps}{}{} ... \includegraphics[bb=0 0 width height]{bla.jpg} ... where width and height are the dimension (in bp) of bla.jpg. It works, but it is not very ergonomic. It would be much nicer if LaTeX were able to read by itself the size of the picture. It should be very easy to do, as in modern TeX distributions, latex is simply pdfetex working in dvi mode, and pdfetex knows how to read jpg files. I tried to print the size of my picture with the following LaTeX code {\setbox0=\hbox{\pdfximage{bla.jpg}\pdfrefximage\pdflastximage} \the\wd0\the\ht0} but it doesn't work in dvi mode, as the executable complains that I dared to use pdfximage in dvi mode, and exits. It seems to me, however, that the previous code should be allowed in dvi mode, as nothing weird for a dvi file arrives on the output list. In other words, I suggest that \pdfximage should be allowed a priori in dvi mode, and that an error should only occur if the program actually tries to write the image on the output file. In that way, it would become possible to patch the graphics package in order to include JPEG files in dvi mode and produce a valid postscript file with my patched dvips. Another possibility, of course, would be to introduce one or two new primitives in pdfetex which would give the size of a picture file. What do you think ? Is either of my suggestions acceptable ? My patch is available on http://tudia.nerim.net/tex/ Thanks, Éric Brunet

3 4

[ pdftex-Bugs-465 ] font expansion & \lastlinefit
by noreply＠sarovar.org 24 Oct '06

24 Oct '06

Bugs item #465, was opened at 2006-01-03 20:05 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=465&group_id=106 Category: hz Group: v1.40.0 Status: Open >Resolution: Postponed Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: font expansion & \lastlinefit Initial Comment: With \lastlinefit > 0, the last line will always be expanded to the maximum (except if it doesn't contain a glue). Furthermore, I wonder whether \lastlinefit should ideally also effect the expansion amount (ie., the last line of the first paragraph should be set in cmr10-25, since the preceding one is set in cmr10-50)? \tracingoutput1 \showboxbreadth\maxdimen \pdftracingfonts1 \pdfadjustspacing2 \pdffontexpand\font 50 50 10 autoexpand \lastlinefit500 \hsize=16cm \input tufte\par \bye, Robert ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-24 12:20 Message: Logged In: YES user_id=710 I spent quite some time on this, but it's unlikely that I am able to fix this bug. Probably we have to wait until some expert finds time to fix this. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-09-01 13:55 Message: Logged In: YES user_id=710 I should work on it and other bugs related to hz stuff, but I haven't found the time to reread relevant codes yet. Please be patient with me. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-01 12:48 Message: Logged In: YES user_id=421 Hartmut? Thanh? Anybody working on this? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=465&group_id=106

1 0

[ pdftex-Bugs-465 ] font expansion & \lastlinefit
by noreply＠sarovar.org 24 Oct '06

24 Oct '06

Bugs item #465, was opened at 2006-01-03 19:05 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=465&group_id=106 Category: hz Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: font expansion & \lastlinefit Initial Comment: With \lastlinefit > 0, the last line will always be expanded to the maximum (except if it doesn't contain a glue). Furthermore, I wonder whether \lastlinefit should ideally also effect the expansion amount (ie., the last line of the first paragraph should be set in cmr10-25, since the preceding one is set in cmr10-50)? \tracingoutput1 \showboxbreadth\maxdimen \pdftracingfonts1 \pdfadjustspacing2 \pdffontexpand\font 50 50 10 autoexpand \lastlinefit500 \hsize=16cm \input tufte\par \bye, Robert ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2006-10-24 10:20 Message: Logged In: YES user_id=710 I spent quite some time on this, but it's unlikely that I am able to fix this bug. Probably we have to wait until some expert finds time to fix this. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-09-01 11:55 Message: Logged In: YES user_id=710 I should work on it and other bugs related to hz stuff, but I haven't found the time to reread relevant codes yet. Please be patient with me. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-01 10:48 Message: Logged In: YES user_id=421 Hartmut? Thanh? Anybody working on this? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=465&group_id=106

1 0

[ pdftex-Bugs-480 ] pdftex offset incorrect with \magnification. Patch included.
by noreply＠sarovar.org 23 Oct '06

23 Oct '06

Bugs item #480, was opened at 2006-02-12 17:12 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=480&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ian Hutchinson (ihutch) Assigned to: Nobody (None) Summary: pdftex offset incorrect with \magnification. Patch included. Initial Comment: Any plain tex file that uses \magnification gives incorrect text placement in pdf. This bug is present in the latest pdftex version 1.21a. It apparently was caused by the introduction of the new variables \pdfvoffset and \pdfhoffset. This bug was not present in older pdftex, e.g. version 3.14159-1.10b, which was part of tetex-2... A simple illustration of the problem is with the trivial file: \magnification \magstep3 %The following parindent and offset changes are not the cause of errors. %They are merely to illustrate them clearly by writing at top left. %Anything other than \magstep0 gives a placement error with pdftex 1.21a. \parindent 0pt \hoffset -1 truein \voffset -1 truein The top. \end With tex and xdvi, the words "The top." are placed at the immediate top left. With pdftex 1.21a and xpdf (or acroread) they are not. With earlier pdftex 1.10b (e.g.) they are. I had an extensive discussion on comp.text.tex with Heiko Oberdiek, most of which is at http://www.codecomments.com/Tex/message784423.html The gist of it is that backward compatibility with plain tex files is very important. As far as possible, it should be preserved transparently. Authors should not be required to hack their files in order for them to render the same in pdf as in dvi. Moreover there is a simple way to provide this compatibility. A reasonable way to fix the bug is to change pdftex.ini and hence pdftex.fmt. (The corresponding pdfetex files ought also to be fixed.) A proposed patched pdftex.ini file is attached. It consists simply of % Thomas Esser, 1998, 2004. public domain. \ifx\pdfoutput\undefined \else \ifx\pdfoutput\relax \else \input pdftexconfig \pdfoutput=1 \fi \fi \input plain \ifx\pdfoutput\undefined \else \ifx\pdfoutput\relax \else \catcode`@=11 \def\m@g{% \mag\count@ \hsize6.5truein\vsize8.9truein\dimen\footins8truein %These commands fix the pdf sizes to be in true units. \mag@fix\pdfhorigin \mag@fix\pdfvorigin \mag@fix\pdfpagewidth \mag@fix\pdfpageheight } \def\mag@fix#1{% #1=\expandafter\convert@truept\the#1\relax } \begingroup \catcode`P=12 \catcode`T=12 \lowercase{% \endgroup \def\convert@truept#1PT{% #1truept% }% }% \catcode`@=12 \fi \fi \dump \endinput I don't know who takes responsibility for pdftex.ini. But clearly this ought to be fixed for all distributions. I care most about tetex, because it is what I use. Thanks, Ian Hutchinson ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2006-10-23 18:49 Message: Logged In: YES user_id=710 oh yes, thanks Phil for the correction. In response to Ian Hutchinson: I am the maintainer of neither pdftex.ini nor pdftex, so I feel that someone else must make the decision. ---------------------------------------------------------------------- Comment By: Philip TAYLOR (chaa006) Date: 2006-10-23 18:21 Message: Logged In: YES user_id=3040 Thanh wrote : I propose that if someone changes magnification then he/she is suppposed to say \pdfhorigin=1in \pdfvorigin=1in Surely they should write \pdfhorigin = 1 true in \pdfvorigin = 1 true in should they not ? I always do, and it certainly has the intended effect. ** Phil. ---------------------------------------------------------------------- Comment By: Ian Hutchinson (ihutch) Date: 2006-10-23 17:49 Message: Logged In: YES user_id=3410 In response to hanthethanh, let me explain once again that the point is that TeX ought always to work the same with both dvi output and pdf output. The latest pdftex breaks that for all documents, old or new, that use \magnification. Of course there are many ways the authors can fix those documents by adding new commands. BUT THEY SHOULD NOT HAVE TO. TeX's archival integrity is far too valuable for us to accept it being broken by this incompatibility. I've shown how it can be transparently fixed. The correction just needs to be incorporated into the distributions ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-23 10:37 Message: Logged In: YES user_id=710 I propose that if someone changes magnification then he/she is suppposed to say \pdfhorigin=1in \pdfvorigin=1in or something similar. An undocumented trick is that if \pdfhorigin or \pdfvorigin is not set (or set to 0) when the first page is shipped out, then they will get 1in as the default value. To get zero origin(s), use 1sp instead of 0. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=480&group_id=106

1 0

[ pdftex-Bugs-480 ] pdftex offset incorrect with \magnification. Patch included.
by noreply＠sarovar.org 23 Oct '06

23 Oct '06

Bugs item #480, was opened at 2006-02-12 17:12 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=480&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ian Hutchinson (ihutch) Assigned to: Nobody (None) Summary: pdftex offset incorrect with \magnification. Patch included. Initial Comment: Any plain tex file that uses \magnification gives incorrect text placement in pdf. This bug is present in the latest pdftex version 1.21a. It apparently was caused by the introduction of the new variables \pdfvoffset and \pdfhoffset. This bug was not present in older pdftex, e.g. version 3.14159-1.10b, which was part of tetex-2... A simple illustration of the problem is with the trivial file: \magnification \magstep3 %The following parindent and offset changes are not the cause of errors. %They are merely to illustrate them clearly by writing at top left. %Anything other than \magstep0 gives a placement error with pdftex 1.21a. \parindent 0pt \hoffset -1 truein \voffset -1 truein The top. \end With tex and xdvi, the words "The top." are placed at the immediate top left. With pdftex 1.21a and xpdf (or acroread) they are not. With earlier pdftex 1.10b (e.g.) they are. I had an extensive discussion on comp.text.tex with Heiko Oberdiek, most of which is at http://www.codecomments.com/Tex/message784423.html The gist of it is that backward compatibility with plain tex files is very important. As far as possible, it should be preserved transparently. Authors should not be required to hack their files in order for them to render the same in pdf as in dvi. Moreover there is a simple way to provide this compatibility. A reasonable way to fix the bug is to change pdftex.ini and hence pdftex.fmt. (The corresponding pdfetex files ought also to be fixed.) A proposed patched pdftex.ini file is attached. It consists simply of % Thomas Esser, 1998, 2004. public domain. \ifx\pdfoutput\undefined \else \ifx\pdfoutput\relax \else \input pdftexconfig \pdfoutput=1 \fi \fi \input plain \ifx\pdfoutput\undefined \else \ifx\pdfoutput\relax \else \catcode`@=11 \def\m@g{% \mag\count@ \hsize6.5truein\vsize8.9truein\dimen\footins8truein %These commands fix the pdf sizes to be in true units. \mag@fix\pdfhorigin \mag@fix\pdfvorigin \mag@fix\pdfpagewidth \mag@fix\pdfpageheight } \def\mag@fix#1{% #1=\expandafter\convert@truept\the#1\relax } \begingroup \catcode`P=12 \catcode`T=12 \lowercase{% \endgroup \def\convert@truept#1PT{% #1truept% }% }% \catcode`@=12 \fi \fi \dump \endinput I don't know who takes responsibility for pdftex.ini. But clearly this ought to be fixed for all distributions. I care most about tetex, because it is what I use. Thanks, Ian Hutchinson ---------------------------------------------------------------------- Comment By: Philip TAYLOR (chaa006) Date: 2006-10-23 18:21 Message: Logged In: YES user_id=3040 Thanh wrote : I propose that if someone changes magnification then he/she is suppposed to say \pdfhorigin=1in \pdfvorigin=1in Surely they should write \pdfhorigin = 1 true in \pdfvorigin = 1 true in should they not ? I always do, and it certainly has the intended effect. ** Phil. ---------------------------------------------------------------------- Comment By: Ian Hutchinson (ihutch) Date: 2006-10-23 17:49 Message: Logged In: YES user_id=3410 In response to hanthethanh, let me explain once again that the point is that TeX ought always to work the same with both dvi output and pdf output. The latest pdftex breaks that for all documents, old or new, that use \magnification. Of course there are many ways the authors can fix those documents by adding new commands. BUT THEY SHOULD NOT HAVE TO. TeX's archival integrity is far too valuable for us to accept it being broken by this incompatibility. I've shown how it can be transparently fixed. The correction just needs to be incorporated into the distributions ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-23 10:37 Message: Logged In: YES user_id=710 I propose that if someone changes magnification then he/she is suppposed to say \pdfhorigin=1in \pdfvorigin=1in or something similar. An undocumented trick is that if \pdfhorigin or \pdfvorigin is not set (or set to 0) when the first page is shipped out, then they will get 1in as the default value. To get zero origin(s), use 1sp instead of 0. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=480&group_id=106

1 0