September 2006 - ntg-pdftex - NTG Mailing Lists

Re: [NTG-pdftex] itshape in beta-20060829-2.2
by Akira Kakuto 04 Sep '06

04 Sep '06

> 2006/9/4, Akira Kakuto <kakuto(a)fsci.fuk.kindai.ac.jp>: > > Is the following example ok in Linux in beta-20060829 ? > > Works for me: Thanks. I think I've fixed the W32 bug. Best regards, Akira

1 0

itshape in beta-20060829-2.2
by Akira Kakuto 04 Sep '06

04 Sep '06

Hi, Is the following example ok in Linux in beta-20060829 ? \documentclass{article} \begin{document} \textit{This is a test.} \end{document} In W32TeX version, pdflatex crashes. Maybe that is a bug in W32 only. I will investigate ASAP. Thanks, Akira

2 1

[CTAN] pax v0.1
by Martin Schröder 04 Sep '06

04 Sep '06

---------- Forwarded message ---------- From: CTAN Announcements <ctan-ann(a)dante.de> Date: 03.09.2006 15:54 Subject: CTAN has a new package: pax v0.1 To: ctan-ann(a)dante.de On Sat, 26 Aug 2006, Heiko Oberdiek submitted a new package pax to CTAN. Location on CTAN: macros/latex/contrib/pax/ License: other (lppl/gpl) ----------------------------------------------------------- >From the README: | A. PROJECT PAX | ============== | | If PDF files are included using pdfTeX, PDF annotations | are stripped. This project tries a solution without | altering pdfTeX. A Java program (pax.jar) parses the PDF file that | will later be included. It writes the data of the annotations | in a file that can be read by TeX. Then a LaTeX package (pax.sty) | extends the graphics package. If a PDF file is included, the package | looks for the file with the annotation data, reads them and puts | the annotations in the right place. | | Project status: experimental -----------------------------------------------------------

3 2

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

03 Sep '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: 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-304 ] Names of expanded fonts not in log output
by noreply＠sarovar.org 01 Sep '06

01 Sep '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: 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: 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-465 ] font expansion & \lastlinefit
by noreply＠sarovar.org 01 Sep '06

01 Sep '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-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-465 ] font expansion & \lastlinefit
by noreply＠sarovar.org 01 Sep '06

01 Sep '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: 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: 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-304 ] Names of expanded fonts not in log output
by noreply＠sarovar.org 01 Sep '06

01 Sep '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: 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: 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-600 ] \pdfdraftmode: results in segfault + can be tricked
by noreply＠sarovar.org 01 Sep '06

01 Sep '06

Bugs item #600, was opened at 2006-08-23 23:51 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=600&group_id=106 Category: None Group: v1.40.0 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: Martin Schröder (oneiros) Summary: \pdfdraftmode: results in segfault + can be tricked Initial Comment: The following gives a segfault here (under cygwin): \pdfdraftmode=1 \immediate\pdfobj{x} %\pdfoutline goto name{x}{y} % with this, too \pdfcompresslevel=9 A \bye >From the terminal: This is pdfTeXk, Version 3.141592-1.40.0-beta-20060822 (Web2C 7.5.5) %&-line parsing enabled. entering extended mode (./bugs.tex [1{/cygdrive/c/Programme/TeXLive/texmf-var/fonts/map/pdftex/updmap/ pdftex.map} 133 [main] pdftex 1780 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) Segmentation fault (core dumped) Also, the following will create a pdf file, although it shouldn't (or at least issue a warning about \pdfdraftmode being issued too late): \immediate\pdfobj{x} \pdfdraftmode=1 A \bye ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-08-29 23:02 Message: Logged In: YES user_id=421 Updated patch that also gives an error in the case of a late \pdfdraftmode=1 ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-08-29 22:43 Message: Logged In: YES user_id=421 Thanks. The attached patch fixes at least the crash. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=600&group_id=106

1 0

[ pdftex-Bugs-481 ] "This can't happen (flushing)" with extra kerning+expansion+ligatures
by noreply＠sarovar.org 01 Sep '06

01 Sep '06

Bugs item #481, was opened at 2006-02-13 19:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=481&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: "This can't happen (flushing)" with extra kerning+expansion+ligatures Initial Comment: With the following test file, pdftex will abort with "This can't happen (flushing)": \pdfadjustspacing=1 \pdffontexpand\font 20 20 4 autoexpand \pdfappendkern=1 \knaccode\font`i=100 \hsize10em foo fii foo foo foo foo % but this works: %foo f{}ii foo foo foo foo \bye Hartmut's analysis was: ----------------------------------- FWIW, this happens in function do_subst_font(). But it starts with auto_expand_kern(), where the given kern indeed is appended to the i of "fi" and also to the 2nd "i". It seems as if at this time "fi" is not yet seen as a ligature. Then in do_subst_font() the "fi" is somehow already a ligature, and now the kern is part of the lig_ptr list (which is wrong). Then font(r) is recursively changed to 51, the expanded font number, and so the kern, which should not be in this list, gets the 51 as its type. But it must be 11 for a kern. Maybe a change should be that the kern does not end up in the lig_ptr list, but should come after the "fi" ligature. No idea, how. ----------------------------------- ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-09-01 12:43 Message: Logged In: YES user_id=421 Is anybody working on this? ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-02-13 21:25 Message: Logged In: YES user_id=929 My text above had a typo, sorry. Before you start searching... it's auto_append_kern(), not auto_expand_kern(). Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=481&group_id=106

1 0