- ntg-pdftex - NTG Mailing Lists

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

06 Nov '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: Robert (schlcht) Date: 2006-11-06 21:34 Message: Logged In: YES user_id=2217 Hi, I've tested this patch and found some problems with it: (I haven't had a look at the first patch.) % ---------------------------------------------------- (1) The kerning amount is wrong/has changed. %...\kern2.32 % instead of (with previous versions) %...\kern 10.00002 % ---------------------------------------------------- (2) There's no kerning before a character if it starts a word. \hsize 9cm \tracingoutput1 \showboxdepth\maxdimen \showboxbreadth\maxdimen \knaccode\font`x=1000 \knbccode\font`x=1000 \pdfappendkern1 \pdfprependkern1 xyxyx xyxyx % ---------------------------------------------------- (3) Kerning doesn't work in lines composed with expanded fonts. \pdfprependkern1 \knbccode\font`:=500 \pdfadjustspacing2 \pdffontexpand\font 20 20 5 autoexpand yyyy: yyyy: yyyy: yyyy: yyyy: yyyy: yyyy: yyyy: yyyy: yyyy: yyyy: % ---------------------------------------------------- (4) Kerning now has this unreliable kind of paragraph scope, so that whether or not it will be applied depends on whether tex needs to hyphenate the paragraph, and whether a word contains a discretionary. \pdfadjustspacing0 \knaccode\font`s=500 \knbccode\font`s=500 \pdfappendkern1 \pdfprependkern1 tasty testing tasty testing tasty testing tasty testing tasty testing \pdfappendkern0 \pdfprependkern0 tasty testing tasty testing tasty testing tasty testing tasty testing \bye % ---------------------------------------------------- % (5) finally, this document gives a segfault % (ok without the patches): \documentclass[10pt,a4paper]{ltxdoc} \def\rmdefault{bch} \begin{document} \begin{multicols}{2} A (\textit{Bcdrea} \end{multicols} \end{document} ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-11-02 08:44 Message: Logged In: YES user_id=710 Thank you Martin for looking at the patch and blessing it. I was struggling with TeX The Program more than a week before I came up with this patch and still I am not sure it doesn't break anything (I didn't claim it fixes bugs #481-484 but said this is an attempt to fix that). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-11-01 17: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 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

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

02 Nov '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-11-02 08:44 Message: Logged In: YES user_id=710 Thank you Martin for looking at the patch and blessing it. I was struggling with TeX The Program more than a week before I came up with this patch and still I am not sure it doesn't break anything (I didn't claim it fixes bugs #481-484 but said this is an attempt to fix that). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-11-01 17: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 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

[ pdftex-Bugs-304 ] Names of expanded fonts not in log output
by noreply＠sarovar.org 01 Nov '06

01 Nov '06

Bugs item #304, was opened at 2005-03-02 18:25 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106 Category: Fonts Group: v1.21a Status: Open Resolution: Accepted >Priority: 3 Submitted By: Robert (schlcht) Assigned to: Hartmut Henkel (hhenkel) Summary: Names of expanded fonts not in log output Initial Comment: When using font expansion, the log output will not contain the names of the expanded fonts but the null character instead (resp. ^^@). %------------------------------------- \pdfadjustspacing=2 \pdffontexpand\font 20 20 5 autoexpand \tracingoutput=1 test \parfillskip 0pt test \bye %------------------------------------- Regards, Robert. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-23 12:23 Message: Logged In: YES user_id=710 Here is an attempt to fix this problem (reversed patch attached). ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-09-03 19:30 Message: Logged In: YES user_id=2217 I've attached an example using Kepler MM (tfm+pfb included, please delete after testing). MM fonts are probably the only case where one would not want to use the autoexpand feature. At first sight, saying "autoexpand" or not doesn't seem to make a difference, since pdftex will always prefer existing expanded fonts (pfb) over autoexpanding them, anyway. However, there are some slight differences in the pdf. This is probably because the provided tfm file is different from the metrics that pdf calculates itself in the case of autoexpand. That is, autoexpand may result in a mismatch between the provided pfb and the calculated tfm, is that correct? ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-09-01 21:02 Message: Logged In: YES user_id=929 currently i even can't get a test file do expansion at all without "autoexpand". E. g. Robert's example above, without "autoexpand", doesn't use expanded fonts. Maybe that's the reason for the missing expand parameter in the log? Can anybody provide a test file for this case? Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-01 12:47 Message: Logged In: YES user_id=421 Is this really a problem, i.e. is there a reason _not_ to use the autoexpand feature in new documents? Hartmut, did you look into this bug? ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2005-10-16 00:24 Message: Logged In: YES user_id=2217 If the font is not autoexpand'ed, its name will still not be written to the log file. (pdftex 1.30.3; same test file, without "autoexpand") Regards, Robert. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-05-12 17:05 Message: Logged In: YES user_id=421 This has been fixed in 1.30.0 ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-30 22:16 Message: Logged In: YES user_id=929 This patch is based of Thanh's change file showfont.ch, which he gave me during EuroTeX2005 (it's also included, renamed here to showfont-thanh.ch). Use showfont.ch for the patch. There is now a new integer variable \pdftracingfonts. It is zero by default, then we get a log like this (see robert050302.log): ...\tenrm t ...\tenrm (+20) e Without font expansion, this default should be compatible with TeX's original log output. If \pdftracingfonts is set to 1 (or greater), we get a more verbose log (see tst-304.log): ...\xivtt (cmtt10(a)14.0pt) t .\xivtt (cmtt10+20(a)14.0pt) e Seems to work with change file showfont.ch coming directly after after hz.ch. Patch only roughly tested with pdfetex, likely to give problems with pdfxtex, as the variable numbering might differ. Log format to be agreed upon... Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106

1 0

[ pdftex-Bugs-565 ] ttf2afm fails to include characters specified with uniXXXX
by noreply＠sarovar.org 01 Nov '06

01 Nov '06

Bugs item #565, was opened at 2006-05-29 16:37 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=565&group_id=106 Category: ttf2afm Group: v1.30.0 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Mike Spivey (spivey) Assigned to: The Thanh Han (hanthethanh) Summary: ttf2afm fails to include characters specified with uniXXXX Initial Comment: If characters are specified in an encoding vector as uniXXXX (with XXXX a hexadecimal unicode value), then these characters are not included in the AFM output, unlike characters that are specified by name. The same goes for characters specifed by position. A suggested patch is attached. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-10-23 12:51 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-23 11:00 Message: Logged In: YES user_id=710 the patch looks good to me. Martin, call you include this in next release? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-25 19:46 Message: Logged In: YES user_id=421 Thanh, ttf2afm is your baby. :-) Pleae check. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=565&group_id=106

1 0

[ pdftex-Bugs-606 ] Forbidden ... while scanning ???
by noreply＠sarovar.org 01 Nov '06

01 Nov '06

Bugs item #606, was opened at 2006-09-16 22:28 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=606&group_id=106 Category: Primitives Group: v1.40.0 Status: Open >Resolution: Postponed Priority: 3 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hartmut Henkel (hhenkel) Summary: Forbidden ... while scanning ??? Initial Comment: \pdftrailer {abc \bye gives ! Forbidden control sequence found while scanning text of \pdftrailer. but \pdfximage {abc \bye or \pdfliteral {abc \bye give ! Forbidden control sequence found while scanning text of ???. Instead of these three question marks there should be the name of the primitive. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-21 14:22 Message: Logged In: YES user_id=421 I've backed out the change; this is low priority and probably needs more changes. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-09-17 21:10 Message: Logged In: YES user_id=929 yes, the patch works, thanks a lot! But there are in fact many more \pdf... primitives that suffer from this problem, actually any with a scan_keyword call before the scan_pdf_ext_toks. After the way how it's done in @<Implement \.{\write}@>=, it seems that a new variable save_cur_cs is not needed if one uses k for this purpose. Needs change of a few k uses to j. But problematic is \pdfoutline as it has another scan_pdf_ext_toks for the attr keyword. Wouldn't these many changes be too risky for 1.40.0? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-17 18:34 Message: Logged In: YES user_id=421 The patch was missing. Fixed. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-17 16:30 Message: Logged In: YES user_id=421 The cause seems to be that some scan_functions loose the meaning of cur_cs, which leads to the ??? when reaching <Tell the user what has run away...@>. The attached (IMHO crude) patch fixes this for the cases you mentioned, but there are probably other cases not found... ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=606&group_id=106

1 0

[ 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

[ 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: 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

Re: [NTG-pdftex] pdftex 1.40 and active characters in French
by Thanh Han The 23 Oct '06

23 Oct '06

Hi, it seems that pdftex cannot do anything to improve the below issues. Sorry. Regards, Thanh On Sat, Oct 21, 2006 at 07:48:00PM +0200, Martin Schroeder wrote: > ---------- Forwarded message ---------- > From: Daniel Flipo <daniel.flipo(a)univ-lille1.fr> > Date: 21.10.2006 19:31 > Subject: pdftex 1.40 and active characters in French > To: Martin Schr�der <martin(a)oneiros.de>, Hans Hagen <pragma(a)wxs.nl> > Cc: Robert Schlicht <w.m.l(a)gmx.net> > > > Hi Martin and Hans, > > I have heard about new kerning facilities coming with pdftex 1.40 and > started playing with them (through the microtype interface, latest > version 1.37 2006-09-09 with \betatrue). I would love to get rid of the > four active characters (:;!?) in babel/frenchb. > > Unfortunately, after discussing with Robert (in copy), it appears that > these new kerning facilities do not quite fulfil what would be needed > for French. I'd like to make a summary of the required specifications > in case you can think of a possible solution for future developments of > pdftex. > > 1) People who type correctly in French, are used to type a (normal) > space before ';:!?'. pdftex 1.40 can add a kern before them, but cannot > do an '\unskip' to remove the typed space. It is hopeless to try to > convince French writers to change their habits and refrain from entering > a space before ';:!?' ;-) > > frenchb currently handles the four (active) punctuation chars ;:!? in > two different ways: > > -- with option \NoAutoSpaceBeforeFDP, frenchb _replaces_ the normal > space with an unbreakable one of the correct width, _if and only if_ a > space (normal or '~') is present before ';:!?'. If no space is typed, > frenchb does nothing and lets the punctuation mark stick to the > preceding word. This avoids to get a spurious space in URLs > (http://...), Windows paths (C:/path), etc. > > -- with option \AutoSpaceBeforeFDP (the default), you can type > carelessly "bonjour!", "bonjour !" or even "bonjour~!", frenchb will > always output it correctly, but then you cannot complain if you get a > spurious space in URLs... > > 2) Another (minor) issue occurs with ':'. Again, there are currently > two different options in frenchb: > > -- Most people agree with our � Imprimerie nationale � that ':' should > be surrounded by two spaces of the same length, the first one being > unbreakable, the other three (;!?) getting a thin space (kern in TeX) > before and a normal one (glue) after. That's what frenchb does by default. > > -- Some typographers argue that ':' should be treated like the other > three, so an option is provided in frenchb to satisfy them. > > AFAIK pdftex 1.40 can add a kern before a character but not a glue, so > the spaces around ':' might look unsymmetrical in the first case if TeX > stretches the second one... > > 3) Guillemets are less problematic because they are currently entered > with commands (\og and \og), not as characters. Spaces after the opening > '�' and before the closing '�' should be unbreakable but stretchable > (currently .8\fontdimen2 plus .3\fontdimen3 minus .8\fontdimen4). > Moreover, a kern after '�' breaks hyphenation of the following word as > Robert already already pointed out on the pdftex bug list. > > Feel free to forward this mail to other pdftex developers if it can be > useful, I would have wished to send it to Than also but I could not find > his current mail address. > > Best wishes and thanks for your attention, > -- > Daniel Flipo > _______________________________________________ > ntg-pdftex mailing list > ntg-pdftex(a)ntg.nl > http://www.ntg.nl/mailman/listinfo/ntg-pdftex

2 1

[ pdftex-Bugs-565 ] ttf2afm fails to include characters specified with uniXXXX
by noreply＠sarovar.org 23 Oct '06

23 Oct '06

Bugs item #565, was opened at 2006-05-29 16:37 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=565&group_id=106 Category: ttf2afm Group: v1.30.0 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Mike Spivey (spivey) Assigned to: The Thanh Han (hanthethanh) Summary: ttf2afm fails to include characters specified with uniXXXX Initial Comment: If characters are specified in an encoding vector as uniXXXX (with XXXX a hexadecimal unicode value), then these characters are not included in the AFM output, unlike characters that are specified by name. The same goes for characters specifed by position. A suggested patch is attached. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-10-23 12:51 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2006-10-23 11:00 Message: Logged In: YES user_id=710 the patch looks good to me. Martin, call you include this in next release? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-25 19:46 Message: Logged In: YES user_id=421 Thanh, ttf2afm is your baby. :-) Pleae check. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=565&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 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-304 ] Names of expanded fonts not in log output
by noreply＠sarovar.org 23 Oct '06

23 Oct '06

Bugs item #304, was opened at 2005-03-02 17:25 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106 Category: Fonts Group: v1.21a Status: Open Resolution: Accepted Priority: 5 Submitted By: Robert (schlcht) Assigned to: Hartmut Henkel (hhenkel) Summary: Names of expanded fonts not in log output Initial Comment: When using font expansion, the log output will not contain the names of the expanded fonts but the null character instead (resp. ^^@). %------------------------------------- \pdfadjustspacing=2 \pdffontexpand\font 20 20 5 autoexpand \tracingoutput=1 test \parfillskip 0pt test \bye %------------------------------------- Regards, Robert. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2006-10-23 10:23 Message: Logged In: YES user_id=710 Here is an attempt to fix this problem (reversed patch attached). ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-09-03 17:30 Message: Logged In: YES user_id=2217 I've attached an example using Kepler MM (tfm+pfb included, please delete after testing). MM fonts are probably the only case where one would not want to use the autoexpand feature. At first sight, saying "autoexpand" or not doesn't seem to make a difference, since pdftex will always prefer existing expanded fonts (pfb) over autoexpanding them, anyway. However, there are some slight differences in the pdf. This is probably because the provided tfm file is different from the metrics that pdf calculates itself in the case of autoexpand. That is, autoexpand may result in a mismatch between the provided pfb and the calculated tfm, is that correct? ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-09-01 19:02 Message: Logged In: YES user_id=929 currently i even can't get a test file do expansion at all without "autoexpand". E. g. Robert's example above, without "autoexpand", doesn't use expanded fonts. Maybe that's the reason for the missing expand parameter in the log? Can anybody provide a test file for this case? Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-01 10:47 Message: Logged In: YES user_id=421 Is this really a problem, i.e. is there a reason _not_ to use the autoexpand feature in new documents? Hartmut, did you look into this bug? ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2005-10-15 22:24 Message: Logged In: YES user_id=2217 If the font is not autoexpand'ed, its name will still not be written to the log file. (pdftex 1.30.3; same test file, without "autoexpand") Regards, Robert. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-05-12 15:05 Message: Logged In: YES user_id=421 This has been fixed in 1.30.0 ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-30 20:16 Message: Logged In: YES user_id=929 This patch is based of Thanh's change file showfont.ch, which he gave me during EuroTeX2005 (it's also included, renamed here to showfont-thanh.ch). Use showfont.ch for the patch. There is now a new integer variable \pdftracingfonts. It is zero by default, then we get a log like this (see robert050302.log): ...\tenrm t ...\tenrm (+20) e Without font expansion, this default should be compatible with TeX's original log output. If \pdftracingfonts is set to 1 (or greater), we get a more verbose log (see tst-304.log): ...\xivtt (cmtt10(a)14.0pt) t .\xivtt (cmtt10+20(a)14.0pt) e Seems to work with change file showfont.ch coming directly after after hz.ch. Patch only roughly tested with pdfetex, likely to give problems with pdfxtex, as the variable numbering might differ. Log format to be agreed upon... Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=304&group_id=106

1 0

[ pdftex-Bugs-565 ] ttf2afm fails to include characters specified with uniXXXX
by noreply＠sarovar.org 23 Oct '06

23 Oct '06

Bugs item #565, was opened at 2006-05-29 14:37 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=565&group_id=106 Category: ttf2afm Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: Mike Spivey (spivey) Assigned to: The Thanh Han (hanthethanh) Summary: ttf2afm fails to include characters specified with uniXXXX Initial Comment: If characters are specified in an encoding vector as uniXXXX (with XXXX a hexadecimal unicode value), then these characters are not included in the AFM output, unlike characters that are specified by name. The same goes for characters specifed by position. A suggested patch is attached. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2006-10-23 09:00 Message: Logged In: YES user_id=710 the patch looks good to me. Martin, call you include this in next release? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-07-25 17:46 Message: Logged In: YES user_id=421 Thanh, ttf2afm is your baby. :-) Pleae check. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=565&group_id=106

1 0

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

22 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-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

vim syntax for web files?
by Thanh Han The 22 Oct '06

22 Oct '06

Hi, does anyone here use vim for editing web (knuthian web) files? Sometimes I got wrong highlighting with tex.web or pdftex.web, but I am not good enough to correct the vim syntax file, so I turn off syntax highlighting for *.web files. The web syntax file coming with vim is made for CWEB files but it is used for web too. If here is some vim guru who can fix that, it would be great. Thanh

1 0

pdftex 1.40 and active characters in French
by Martin Schröder 21 Oct '06

21 Oct '06

---------- Forwarded message ---------- From: Daniel Flipo <daniel.flipo(a)univ-lille1.fr> Date: 21.10.2006 19:31 Subject: pdftex 1.40 and active characters in French To: Martin Schröder <martin(a)oneiros.de>, Hans Hagen <pragma(a)wxs.nl> Cc: Robert Schlicht <w.m.l(a)gmx.net> Hi Martin and Hans, I have heard about new kerning facilities coming with pdftex 1.40 and started playing with them (through the microtype interface, latest version 1.37 2006-09-09 with \betatrue). I would love to get rid of the four active characters (:;!?) in babel/frenchb. Unfortunately, after discussing with Robert (in copy), it appears that these new kerning facilities do not quite fulfil what would be needed for French. I'd like to make a summary of the required specifications in case you can think of a possible solution for future developments of pdftex. 1) People who type correctly in French, are used to type a (normal) space before ';:!?'. pdftex 1.40 can add a kern before them, but cannot do an '\unskip' to remove the typed space. It is hopeless to try to convince French writers to change their habits and refrain from entering a space before ';:!?' ;-) frenchb currently handles the four (active) punctuation chars ;:!? in two different ways: -- with option \NoAutoSpaceBeforeFDP, frenchb _replaces_ the normal space with an unbreakable one of the correct width, _if and only if_ a space (normal or '~') is present before ';:!?'. If no space is typed, frenchb does nothing and lets the punctuation mark stick to the preceding word. This avoids to get a spurious space in URLs (http://...), Windows paths (C:/path), etc. -- with option \AutoSpaceBeforeFDP (the default), you can type carelessly "bonjour!", "bonjour !" or even "bonjour~!", frenchb will always output it correctly, but then you cannot complain if you get a spurious space in URLs... 2) Another (minor) issue occurs with ':'. Again, there are currently two different options in frenchb: -- Most people agree with our « Imprimerie nationale » that ':' should be surrounded by two spaces of the same length, the first one being unbreakable, the other three (;!?) getting a thin space (kern in TeX) before and a normal one (glue) after. That's what frenchb does by default. -- Some typographers argue that ':' should be treated like the other three, so an option is provided in frenchb to satisfy them. AFAIK pdftex 1.40 can add a kern before a character but not a glue, so the spaces around ':' might look unsymmetrical in the first case if TeX stretches the second one... 3) Guillemets are less problematic because they are currently entered with commands (\og and \og), not as characters. Spaces after the opening '«' and before the closing '»' should be unbreakable but stretchable (currently .8\fontdimen2 plus .3\fontdimen3 minus .8\fontdimen4). Moreover, a kern after '«' breaks hyphenation of the following word as Robert already already pointed out on the pdftex bug list. Feel free to forward this mail to other pdftex developers if it can be useful, I would have wished to send it to Than also but I could not find his current mail address. Best wishes and thanks for your attention, -- Daniel Flipo

1 0

[ pdftex-Bugs-609 ] Pdf "convert" primitives bug
by noreply＠sarovar.org 21 Oct '06

21 Oct '06

Bugs item #609, was opened at 2006-09-28 18:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=609&group_id=106 Category: Primitives Group: v1.40.0 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Taco Hoekwater (taco) >Summary: Pdf "convert" primitives bug Initial Comment: The problem: When tex calls `conv_toks()' to execute `convert' commands, a string may already be being built. A call to scan_toks (pdf_scan_ext_toks) at that moment will incorporate that partial string to the argument of the `convert' primitive, and erase it from the output. Example code: \message{\pdfmdfivesum{knuth}} \input knuth\pdfmdfivesum{} \bye Affected primitives: \pdfescapestring \pdfescapename \pdfescapehex \pdfunescapehex \pdffilemoddate \pdffilesize \pdffiledump \pdfmdfivesum \pdfstrcmp The needed fix: Somewhen before calling scan_pdf_ext_toks, you have to store the partial string as a true tex string, then its `partialness' has to be restored sometime later before leaving conv_toks(). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-10-21 15:57 Message: Logged In: YES user_id=421 A patch for this will be included in the next version (1.40). ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-10-04 16:43 Message: Logged In: YES user_id=1608 patch against pdftex.web from 20060928 attached. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-09-28 18:52 Message: Logged In: YES user_id=1608 sorry, it is a bug, of course ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=609&group_id=106

1 0