- ntg-pdftex - NTG Mailing Lists

bug?
by Hans Hagen 11 Jan '05

11 Jan '05

stream BT /F1 11.9552 Tf 280.537 760.6529 Td[(1)]TJ -209.67 -58.2684 Td[(test:)]TJ ET endstream this extra empty line looks like a 'bug' to me (only latest version) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

4 4

[ pdftex-Patches-257 ] Experimental patch for pdftex character protrusion
by noreply＠sarovar.org 11 Jan '05

11 Jan '05

Patches item #257, was opened at 2005-01-10 21:43 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=257&group_id=106 Category: None Group: Unstable (example) Status: Open Resolution: None Priority: 3 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: Experimental patch for pdftex character protrusion Initial Comment: Normally items inside a \hbox are not considered for protrusion. With this experimental patch also nested \hboxes at the left and right margin are recursively searched for items with \lpcode or \rpcode, and the outmost containing boxes are protruded correspondingly. This seems to be practical e. g. if an elevated \footnote{foo} (LaTeX) index happens to be at the right margin; in this case the footnote index normally is placed too far inward the line. This disturbance was detected by Peter Muthesius in an de.comp.text.tex news thread "pdfcprot und Ziffern am rechten Rand" started Sat Jan 08 14:05:23 CET 2005. Rough experimental patch, rudimentarily tested with left and right protrusion, see test file xx.tex with output xx.pdf. Just for discussion. No warranty. Have fun! Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=257&group_id=106

3 3

PNG inclusion progress
by Taco Hoekwater 10 Jan '05

10 Jan '05

Hi all, As I said last week, i've been working on PNG inclusion, and I have reached the point where I have a 'proof of concept' that needs checking before I continue. Would somebody with an AR >= 6.0 please see if this file loads OK? http://tex.aanhet.net/context/png-test.pdf This is a compile of the suite of PNG test images, as seen on http://www.libpng.org/pub/png/pngsuite.html The one-pixel images do not work, but I expect that is a bug in the Reader (they look fine in the PDF source). I cannot test the pdf file myself, because AR on Linux does not accept 16-bit images yet, and I do not own any of the platforms that *are* supported by AR 6/7 (sigh). I really need to know if the file is ok, so I can change my C code from 'quick&dirty' to 'production' style. :-) And while at it, I have some technical questions as well: - The current code assumes that transparancy should always be used whenever it is a) present and b) the pdf version allows it (PDF-1.4). Is this reasonable? - There is a similar question for 16-bit color samples (PDF-1.5) - My current code uses 1.0 for the 'screen gamma' and 0.45455 (==1/2.2) for the 'assumed file gamma'. Do these 'gamma values' need parameterisation? - My code ignores bKGD (the default background color), because otherwise transparancy inclusion would be pointless. That is, unless someone would want to load a transparant PNG with the background applied but without transparancy? - I currently ignore all color management stuff in the PNG (cHRM, sRGB, iCCP chunks). I do not know enough about it at the moment, and I wonder if anybody is immediately interested anyway? Besides, color management would require other changes to pdftex as well, I assume? - (this is an unrelated question) I consider adding downsampling support for PNG images, but it would need a new primitive. Something like \pdfoptionimageresolution ? Greetings, Taco

2 1

ttf fonts reported as non-subsetted
by The Thanh Han 10 Jan '05

10 Jan '05

Hi, I must have thought of it while implementing the subset tags for type1 fonts. However, to be honest, I don't remember the reason why I left name records of ttf fonts without subset tags (I guess laziness is the correct answer :). Anyway it would be nice to have it fixed. I will download the truetype specification again and look at this issue. Regards, Thanh > Hi, > > there seem to be a few inconsistencies in the way how pdftex handles > Type1 vs. TT fonts: > > 1. Subsetted Type1 fonts get a 6-character with + sign extension like > > /BaseFont /FCLRSI+CMR10 > > in the PDF file, but TT fonts don't get this; there it's simply > > /BaseFont /CMR10 > > Therefore even subsetted TT fonts are normally _not_ detected as > subsetted by the viewer or pdffonts program. > > So this should probably be added to the TTF routines... > > 2. For Type1 fonts, the /BaseFont entry is always taken from the > /FontName entry in the font. However for TT fonts the /BaseFont entry in > the PDF file is copied from the tfmname (!) field in the mapline, if no > psname is stated there, else it's taken from the psname of the mapline. > E. g. > > \pdfmapline{+Packa___ <8r.enc <PackardAntique.ttf} > > gives in the PDF file: > > /BaseFont /Packa___ > > (which should be PackardAntique-Regular), whereas > > \pdfmapline{+Packa___ FOO <8r.enc <PackardAntique.ttf} > > gives > > /BaseFont /FOO > > Here maybe always the /FontName from the TT font should be taken; it's > an ASCII string with NameID 6 in the TTF name record. Then it would be > consistent with Type1. > > Regards, Hartmut > _______________________________________________ > ntg-pdftex mailing list > ntg-pdftex(a)ntg.nl > http://www.ntg.nl/mailman/listinfo/ntg-pdftex > > > >

1 0

Re: [NTG-pdftex] PNG handling, transparency
by Taco Hoekwater 10 Jan '05

10 Jan '05

>From a thread from November: Hartmut Henkel wrote: > seems so yes: the alpha channel, if it would be properly extracted. Or > use a separate image, tried just the maybe most trivial case: Assuming nobody else is doing anything with it a.t.m., I'll work on that next week (need it for work, so ..) Greetings, Taco

2 1

Re: [NTG-pdftex] [ pdftex-Bugs-242 ] Assertion failure when including pdf file without embedded fonts
by The Thanh Han 07 Jan '05

07 Jan '05

Hi, > Not yet tried Akira's patch, but there is another problem (ooops they > are piling up): > > Formerly one could write "!foo.pfb" in the mapfile and the font file > would not be embedded. So it's also documented. This has silently > changed, now one can just write "foo.pfb" to have it not embedded. > (Writing "<foo.pfb" would embed the subset, and "<<foo.pfb" the whole > font.) > > Now "!foo.pfb" will be treated by the inner pdftex workings as font with > name "!foo.pfb" which is not found, obviously. So pdftex munges > "!foo.pfb" and "foo.pfb" differently. formerly both "foo.pfb" and "!foo.pfb" were possible, but they had different meaning: "foo.pfb" means "read the font file to extract all parameters but do not embed it" while "!foo.pfb" means "don't read anything", and the font descriptor is not created. "!foo.pfb" only works if the font is installed onto the system where the pdf is being viewed -- it works more or less similarly to the 14 base fonts, except that the 14 base fonts are built into acroreader while foo.pfb must be installed onto the system properly (which is not easy at all on unix systems). The reason I implemented it was that I though it would speed up the time acrobat reader loads such a document, which was important for efficient edit-compile-view-edit cycle while pdftexing. I think we should drop "!foo.pfb". Thanh

2 1

\systemcallmode
by The Thanh Han 07 Jan '05

07 Jan '05

Hi, I feel that this is web2c-specific and therefore Olaf might want to do that :) Thanh > Hi, > > I'd like to see a primitive > > \pdfsystemcallmode > > which is 0 when write18 is disabled and 0 when enabled > > of course, it would be nicer to have a more generic > > \systemcallmode > > i'm already be happy if > > \ifeof18 > > would work -) > > Hans

2 1

pdftex-bug-242
by The Thanh Han 07 Jan '05

07 Jan '05

Hi, > On Sun, 5 Dec 2004, h h extern wrote: > > > >>> > Now "!foo.pfb" will be treated by the inner pdftex workings as font > >>> > with name "!foo.pfb" which is not found, obviously. So pdftex munges > >>> > "!foo.pfb" and "foo.pfb" differently. > > > >> > >> hm, i suggest to drop the ! (since we need the first char for +-=) > > > the ! has been in for long time, so shouldn't it stay there for > backwards compatibility? Virtually nobody knows about the new !-less > case as it's documented nowhere, so anybody wanting this no-load feature > will use the ! sign. > > And the +-= go in front of the tfm names, not the fontfile names. So +-= > doesn't collide with the ! anyway. > > > >> and stick t < and << > > > It's in my suggested patch (does the same with and without !) but this > can be left out if wanted. I think the ! has ever been used only once by me during some testing. We should drop it, as it is pretty useless. The case without anything (ie "foo foo.pfb") can be useful, however I am not aware of any practical use of this. In short, it can be used so font files are not embedded (to make the pdf smaller), and at the same time keep the document nearly the same as in case the fonts are embedded (only metrics are copied to pdf; the glyphs will be rendered by acrobat reader). Thanh

2 1

testing -- please ignore
by The Thanh Han 05 Jan '05

05 Jan '05

test

1 0

Type1, TTF, subsetting, basefont
by Hartmut Henkel 29 Dec '04

29 Dec '04

Hi, there seem to be a few inconsistencies in the way how pdftex handles Type1 vs. TT fonts: 1. Subsetted Type1 fonts get a 6-character with + sign extension like /BaseFont /FCLRSI+CMR10 in the PDF file, but TT fonts don't get this; there it's simply /BaseFont /CMR10 Therefore even subsetted TT fonts are normally _not_ detected as subsetted by the viewer or pdffonts program. So this should probably be added to the TTF routines... 2. For Type1 fonts, the /BaseFont entry is always taken from the /FontName entry in the font. However for TT fonts the /BaseFont entry in the PDF file is copied from the tfmname (!) field in the mapline, if no psname is stated there, else it's taken from the psname of the mapline. E. g. \pdfmapline{+Packa___ <8r.enc <PackardAntique.ttf} gives in the PDF file: /BaseFont /Packa___ (which should be PackardAntique-Regular), whereas \pdfmapline{+Packa___ FOO <8r.enc <PackardAntique.ttf} gives /BaseFont /FOO Here maybe always the /FontName from the TT font should be taken; it's an ASCII string with NameID 6 in the TTF name record. Then it would be consistent with Type1. Regards, Hartmut

4 5

Re: [NTG-context] bookmark & UTF-8 accented characters
by Hans Hagen 27 Dec '04

27 Dec '04

Hi Thanh, In order to get bookmarks to display something else than pdfdoc encoding, we need a fix (extension); we have: \pdfoutline user {...} count ... {text} but also need: \pdfoutline user {...} count ... objrefnr I'll send you a file that shows why -) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

1 0

[ pdftex-Bugs-112 ] Message " output format initialized to" is not always right
by noreply＠sarovar.org 27 Dec '04

27 Dec '04

Bugs item #112, was opened at 2004-09-09 12:13 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=112&group_id=106 Category: None Group: v1.20a >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Martin Schröder (oneiros) Assigned to: Nobody (None) >Summary: Message "output format initialized to" is not always right Initial Comment: The "output format initialized to DVI|PDF" is issued to early, which may lead to confusing results. See the thread "pdftex -ini" at http://www.ntg.nl/pipermail/ntg-pdftex/2004-September/000727.html ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-12-22 15:53 Message: Logged In: YES user_id=421 This has been fixed in 1.20b ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=112&group_id=106

2 1

[ pdftex-Feature Requests-254 ] fontexpansion, dvi output
by noreply＠sarovar.org 22 Dec '04

22 Dec '04

Feature Requests item #254, was opened at 2004-12-23 02:36 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=254&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: fontexpansion, dvi output Initial Comment: Hello developers, I'd like to use the autoexpand feature with dvips. Are there any plans to make pdftex write the autoexpanded tfm files to the current directory, perhaps even generating a map file? Cheers, Michael ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=254&group_id=106

1 0

Re: [NTG-pdftex] 1.20b/1.21a
by Akira Kakuto 22 Dec '04

22 Dec '04

Martin wrote: > I have problems compiling the latest sources out-of-tree, most > likely because of changes to utils.c: The definition of > ptexbanner has moved. ptexbanner is defined in texmfmp.c. I think you probably did not replace texmfmp.c with the new one. Best regards, Akira

8 27

[ pdftex-Bugs-250 ] writet1.c has problems with HUGE fonts. Patch.
by noreply＠sarovar.org 22 Dec '04

22 Dec '04

Bugs item #250, was opened at 2004-12-11 19:15 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=250&group_id=106 Category: Fonts Group: v1.20a >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hartmut Henkel (hhenkel) Summary: writet1.c has problems with HUGE fonts. Patch. Initial Comment: Font GoudyIn.pfb causes pdftex segfault, see the README coming with the patch. This tries a fix by dynamic allocation of buffers. As a by-result, PFB and PFA font embedding speed seems to be increased. Needs more testing... ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-12-22 15:53 Message: Logged In: YES user_id=421 This has been fixed in 1.20b ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2004-12-12 10:00 Message: Logged In: YES user_id=929 Tried to force re-allocations and made tests with pdftex and dvipsk, see attached .tgz file. Seems to run ok. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2004-12-11 19:39 Message: Logged In: YES user_id=1608 My version pdfxtex did not exactly segfault, instead it gave the following pdftex_warning(): CharString: invalid access (1) to stack (0 entries) (and gdb showed a somewhat corrupt backtrace, probably both a symptom of the wild pointer). The patch fixed the problem, and I am now looking at a correct PDF document. And I also think it is somewhat faster than before. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=250&group_id=106

1 0

[ pdftex-Bugs-199 ] font expansion: characters may vanish
by noreply＠sarovar.org 22 Dec '04

22 Dec '04

Bugs item #199, was opened at 2004-09-22 23:13 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=199&group_id=106 Category: hz Group: v1.20a >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody (None) Assigned to: The Thanh Han (hanthethanh) Summary: font expansion: characters may vanish Initial Comment: For extremely large shrink values, characters may not be visible in the pdf output (although the fonts seem to be embedded), e.g. in the following file: %---------------------------------------------- \hsize220pt \pdfadjustspacing=2 \font\testfont=cmr17 at 90pt\testfont \pdffontexpand\font 0 1000 100 autoexpand \efcode\font`\s=500 \efcode\font`\e=500 \efcode\font`\y=500 see what you get\penalty-10000 \bye %---------------------------------------------- or even worse: %---------------------------------------------- \hsize180pt \pdfadjustspacing=2 \font\testfont=cmr17 at 90pt\testfont \pdffontexpand\font 0 1000 100 autoexpand see what you get\penalty-10000 \bye %---------------------------------------------- The font `cmr17-Extend_100' will not be visible. I only managed to achieve this effect with extremely large font sizes, which may or may not be related (it could also be that I didn't find the `magic' \hsize). If you force the characters to shrink even more, for example by setting \hsize to 120pt in the latter test file, the unexpanded font will be used, thus printing the characters over each other. Regards, Robert <w.m.l(a)gmx.net> PS. I didn't bother to create expanded fonts, so I cannot tell whether it depends on the autoexpand feature. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-12-22 15:53 Message: Logged In: YES user_id=421 This has been fixed in 1.20b ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2004-10-01 20:41 Message: Logged In: YES user_id=929 tiny patch tries to solve this bug. See README and PDF test file included. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-10-01 17:17 Message: Logged In: YES user_id=421 I you mean the effect in the attached pdf: This is either a bug in Jaws (png attached) or a bug in pdftex. gs 8.30, harlequin 5.3.4a and AR 5 all display the file distorted. :-( ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2004-09-29 00:06 Message: Logged In: NO But the problem I mentioned above in the last paragraph isn't related to Acrobat Reader, is it? % ------------------------------------------ \hsize35pt \pdfadjustspacing=2 \font\testfont=cmr12\testfont \pdffontexpand\font 0 1000 100 autoexpand text text text text\penalty-10000 \bye % ------------------------------------------ Seems like a sanity check is missing somewhere. If my guess is right, pdftex tries to use the font `cmr17-Extend_0', which (incorrectly) translates into the base font. What it should probably do is use the smallest available expanded font, i.e. in this case Extend_100, and make the line overfull. Regards, Robert. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-09-27 17:27 Message: Logged In: YES user_id=421 An Acrobat Reader bug. :-) ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2004-09-23 00:02 Message: Logged In: NO Obviously, I filed this report too early. Sorry about that. It is not a pdftex bug, but appears to be a bug in Acrobat Reader 6. (Just to tell you what I saw:) At zoom level 200% or larger, the font most shrunk (Extend_100) is not visible on screen. That is, in the first example, I only see "See y e", in the second, nothing at all. However, if I zoom out, the characters re-appear. Sorry for not zooming out earlier. Regards, Robert. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=199&group_id=106

1 0

[ pdftex-Bugs-210 ] Map files with many (> 255) different encodings make pdftex segfault. Bug fix by AVL tree.
by noreply＠sarovar.org 22 Dec '04

22 Dec '04

Bugs item #210, was opened at 2004-10-14 02:28 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=210&group_id=106 Category: None Group: v1.20a >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) >Summary: Map files with many (>255) different encodings make pdftex segfault. Bug fix by AVL tree. Initial Comment: See E-Mail describing problem with typesetting chinese texts: Date: Wed, 13 Oct 2004 07:25:41 +0200 From: Lutz Haseloff <Lutz.Haseloff(a)lbapdm.brandenburg.de> Reply-To: mailing list for ConTeXt users <ntg-context(a)ntg.nl> To: mailing list for ConTeXt users <ntg-context(a)ntg.nl> Subject: Re: [NTG-context] Update to Pdfetex 1.20a Hans Hagen schrieb: > Lutz Haseloff wrote: > > > Hi Hans, Hi all, > > > > \loadmapfile[gbk]> > > > > > Is this a bug in pdfetex? > > > welcome to the non downward compatible changes in tex and friends > > \usemodule[chinese] > > \usemodule[chi-simplified] > > \starttext > > \section{test} > > \stoptext Patch seems to be solved by the patch in the attached file. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-12-22 15:53 Message: Logged In: YES user_id=421 This has been fixed in 1.20b ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2004-10-14 22:07 Message: Logged In: YES user_id=929 Fixed patch for built-in encodings. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=210&group_id=106

1 0

[ pdftex-Bugs-204 ] pdftex.1.gz: --help has basic info that man page lacks
by noreply＠sarovar.org 22 Dec '04

22 Dec '04

Bugs item #204, was opened at 2004-09-27 17:26 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=204&group_id=106 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 4 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) Summary: pdftex.1.gz: --help has basic info that man page lacks Initial Comment: Frank Küster reports things missing in the man page that are in the output of "pdftex --help". See http://www.ntg.nl/pipermail/ntg-pdftex/2004-September/000767.html ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-12-22 15:53 Message: Logged In: YES user_id=421 This has been fixed in 1.20b ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=204&group_id=106

1 0

[ pdftex-Bugs-115 ] character protrusion: some characters will not be protruded
by noreply＠sarovar.org 22 Dec '04

22 Dec '04

Bugs item #115, was opened at 2004-09-10 23:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=115&group_id=106 Category: hz Group: v1.20a >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody (None) Assigned to: The Thanh Han (hanthethanh) Summary: character protrusion: some characters will not be protruded Initial Comment: Some characters will not be protruded into the right margin, namely: `-', `--', and `---', if entered like that. When they occur as \hyphenchar, or as a single character (e.g. \char123), everything's fine. With the EC fonts, the same happens for some quote characters. Here's a plain TeX file showing the problem: ---------------------------------------------------- \tracingoutput 1 \showboxbreadth \maxdimen \showboxdepth \maxdimen \pdfprotrudechars=2 \hsize10em \def\testprotrusion#1{#1\dotfill #1\penalty-10000} \font\testfont=cmr10\testfont \newcount\charcount \charcount=0 \loop \rpcode\font\charcount=1000 \advance\charcount 1 \ifnum\charcount < 256 \repeat \noindent \testprotrusion{A}% OK \testprotrusion{-}% \testprotrusion{--}% \testprotrusion{---}% \testprotrusion{itworks\-likethis}% \testprotrusion{\char123}% \testprotrusion{\char124}% \font\testfont=ecrm10\testfont \charcount=0 \loop \rpcode\font\charcount=1000 \advance\charcount 1 \ifnum\charcount < 256 \repeat \noindent \testprotrusion{``}% \testprotrusion{''}% \testprotrusion{\char13}% \quotedblbase \testprotrusion{\char18}% \quotesinglbase \testprotrusion{Z}% OK \bye ---------------------------------------------------- I don't know whether that might be related, but in all cases, something is being inserted between the character itself and the right margin by TeX (a discretionary for the dashes, a \kern for the quote characters). (This is the same bug as reported in the dctt thread `Randausgleich von Binde- und Trennstrich', 29.8.04) Regards, Robert. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-12-22 15:53 Message: Logged In: YES user_id=421 This has been fixed in 1.20b ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2004-10-01 16:23 Message: Logged In: YES user_id=929 Hi Robert and Thanh, response on Robert's mail. Please check the test files. Thanh, please comment, help. Thanks a lot! Best Regards Hartmut ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2004-09-29 00:09 Message: Logged In: NO In the README to the patch, you say: > To scroll back over unwanted things I now have extended > the discardable() macro. There was an error in the > original macro anyway, as > > ((type(#) = kern_node) and (subtype(#) <> explicit)) > > is to be discarded, but > > ((type(#) = kern_node) and (subtype(#) = explicit)) > > is not. Does that mean that `\kern1pt A\kern1pt' will not get protruded? And, what about `\kern1pt\unkern A\kern1pt\unkern'? Unfortunately, I'm not able to to test your patch. Could you (or somebody) run this file, and comment on the output, please, or upload the PDF? % ----------------------------------------------------- \pdfprotrudechars=2 \hsize5em \def\testprotrusion#1{#1 \hfill #1\penalty-10000} \font\testfont=cmr10\testfont \lpcode\font`\A=1000 \rpcode\font`\A=1000 \noindent \testprotrusion{A} \testprotrusion{\hskip0ptA\hskip0pt} \testprotrusion{\kern1exA\kern1ex} \testprotrusion{\kern1ex\unkern A\kern1ex\unkern} \testprotrusion{\kern1ex\unkern\kern1ex\unkern A\kern1ex\unkern\kern1ex\unkern} \testprotrusion{\kern1ex\kern1ex\unkern\unkern A\kern1ex\kern1ex\unkern\unkern} \testprotrusion{Z} \bye % ----------------------------------------------------- My concern is about LaTeX packages which might insert kerns as markers. For example, the csquotes package, or the footmisc package. I suppose that protrusion should take place at every point where TeX allows a line break -- is that correct? Regards, Robert ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2004-09-20 01:39 Message: Logged In: YES user_id=929 This patch should solve now the problems with character protrusion, particularily also in combination with font expansion, see the attached PDF files and the README file. Have fun! :-) Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2004-09-19 19:09 Message: Logged In: YES user_id=929 still problems with expanded fonts, see PDF ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2004-09-19 15:49 Message: Logged In: YES user_id=929 This patch should work now, see PDF files in the tarball. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2004-09-19 14:42 Message: Logged In: YES user_id=929 Patch tries to solve the bug. Seems to run with Robert's example. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=115&group_id=106

1 0

[ pdftex-Bugs-242 ] Assertion failure when including pdf file without embedded fonts
by noreply＠sarovar.org 22 Dec '04

22 Dec '04

Bugs item #242, was opened at 2004-12-02 15:31 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=242&group_id=106 Category: Fonts Group: v1.20a >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody (None) Assigned to: Hartmut Henkel (hhenkel) Summary: Assertion failure when including pdf file without embedded fonts Initial Comment: See included shell script ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-12-22 15:53 Message: Logged In: YES user_id=421 This has been fixed in 1.20b ---------------------------------------------------------------------- Comment By: Thomas Esser (tetex) Date: 2004-12-03 00:30 Message: Logged In: YES user_id=1230 I can reproduce this bug after updmap --setoption pdftexDownloadBase14 false Thomas ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=242&group_id=106

1 0

[ pdftex-Bugs-116 ] character protrusion: pdftex may hang
by noreply＠sarovar.org 22 Dec '04

22 Dec '04

Bugs item #116, was opened at 2004-09-10 23:58 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=116&group_id=106 Category: hz Group: v1.20a >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Nobody (None) Assigned to: The Thanh Han (hanthethanh) Summary: character protrusion: pdftex may hang Initial Comment: pdfTeX will fail on the following LaTeX file: ---------------------------------------------------- \pdfprotrudechars 2 \documentclass{minimal} \begin{document} \fontsize{7}{8}\selectfont This paragraph consists of more than two lines. This paragraph consists of more than two lines. This paragraph consists of more than two lines. %% same for this paragraph: % This is \hfill an empty line \end{document} ---------------------------------------------------- pdfTeX will hang while building the paragraph, so it seems. This does not happen with other font sizes. Also, it somehow seems to depend on the fonts preloaded in the format file. If I change this line in preload.ltx: \DeclarePreloadSizes{OT1}{cmr}{m}{n}{5,7,10} so that the font for size 10 will be loaded first, and recreate the format, all is well. I am using: This is pdfeTeX, Version 3.141592-1.20a-2.2 (MiKTeX 2.4)) Regards, Robert. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-12-22 15:53 Message: Logged In: YES user_id=421 This has been fixed in 1.20b ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2004-10-14 15:11 Message: Logged In: NO I have also had this problem with v1.10a and v1.20a. The problem only occurs with \pdfprotrudechars=2 (not when it is 1). Changing the font-size sometimes fixes it, as does changing the font encoding (presumably this alters the line breaking sufficiently not to bring about the specific conditions that cause the hang). ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2004-09-17 00:18 Message: Logged In: YES user_id=929 seems it's a loop in hz.ch, function total_pw(), always returning to the reswitch: label. I don't know what's going on, but supposing that the current line loop or whatever should end when the post_break(l) is reached, just shifting the goto reswitch; to this place: decr(n); end; goto reswitch; end; end; total_pw := left_pw(l) + right_pw(r); end; seems to make it work. No idea how to test it... ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=116&group_id=106

1 0

[ pdftex-Bugs-113 ] \pdftexbanner identifies pdfetex and pdfxtex as pdftex
by noreply＠sarovar.org 22 Dec '04

22 Dec '04

Bugs item #113, was opened at 2004-09-09 12:16 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=113&group_id=106 Category: None Group: v1.20a >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Martin Schröder (oneiros) Assigned to: Nobody (None) Summary: \pdftexbanner identifies pdfetex and pdfxtex as pdftex Initial Comment: Also make sure that the /PTEX.-keys inserted by the programs correctly identify the programs, not only pdftex. For pdf{e|x}tex, the information should also include the eTeX-version. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-12-22 15:53 Message: Logged In: YES user_id=421 This has been fixed in 1.20b ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=113&group_id=106

1 0

[ pdftex-Bugs-63 ] Test
by noreply＠sarovar.org 22 Dec '04

22 Dec '04

Bugs item #63, was opened at 2004-04-20 17:04 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=63&group_id=106 Category: PDF inclusion Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Martin Schröder (oneiros) Summary: Test Initial Comment: test ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=63&group_id=106

1 0

Re: Re: [NTG-pdftex] 1.20b-rc6
by The Thanh Han 21 Dec '04

21 Dec '04

Hi, I am sorry not to be able to check it out, as my laptop is broken and I don't have a telephone link at home yet, so the only thing I can do now is to visit some internet cafe to check mail and reply to those urgent ones. If thing don't improve for another 2-3 weeks I will buy a new laptop. Thanh -----Original Message----- From: Martin Schröder <ms(a)artcom-gmbh.de> To: ntg-pdftex(a)ntg.nl Date: Mon, 20 Dec 2004 17:45:50 +0100 Subject: Re: [NTG-pdftex] 1.20b-rc6 > p4 describe -s 6664 Change 6664 by ms@artcom on 2004/12/20 17:34:46 pdftex: 1.20b-rc6 Affected files ... .... //depot/Build/source.development/TeX/texk/web2c/pdftexdir/NEWS#76 edit .... //depot/Build/source.development/TeX/texk/web2c/pdftexdir/pdftex.ch#159 edit .... //depot/Build/source.development/TeX/texk/web2c/pdftexdir/writet1.c#21 edit This has the last patch from Hartmut for bug #250. If nothing serious happens I plan a release on Wednesday. tarball is at pdftex.sarovar.org and in the beta branch at http://sarovar.org/projects/pdftex/ Best regards Martin -- Martin Schröder, ms(a)artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de _______________________________________________ ntg-pdftex mailing list ntg-pdftex(a)ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-pdftex

1 0

[ pdftex-Feature Requests-252 ] current page object number
by noreply＠sarovar.org 14 Dec '04

14 Dec '04

Feature Requests item #252, was opened at 2004-12-14 16:47 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=252&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: current page object number Initial Comment: Dear PdfTeX-developpers, sometimes the reference to the current page object is needed within the implementation of another pdf object. As an example may serve the `Screen Annotation' several interactive PDF features rely on. Currently, the \pdfpageref command, which takes a page number as argument, can be used for this purpose. It is difficult, however, to maintain a reliable page counter as the attached file demonstrates. It uses the `everyshi' package by M. Schroeder. On the first line of every page a wrong object number is being output. It would be very nice to have a command like \pdfcurrentpageref to be implemented in pdftex. Thanks for your attention, Alexander Grahn ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=252&group_id=106

1 0