- ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-274 ] \unhbox kills protrusion
by noreply＠sarovar.org 09 Feb '05

09 Feb '05

Bugs item #274, was opened at 2005-01-31 03:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=274&group_id=106 Category: hz Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: \unhbox kills protrusion Initial Comment: Protrusion will break when boxes containing protruded characters are \unhbox'ed. I've stumbled upon this when using edmac/ledmac, which decomposes each paragraph into lines, then reassembling them. I wasn't sure whether protrusion is supposed to survive this treatment but it does if one uses \unhcopy instead of \unhbox. Here's a greatly reduced example: %-------------------------------------------- \font\testfont=cmr10 \testfont \pdfprotrudechars=2 \rpcode\font`\-=1000 \parindent0pt \hsize=126pt \newbox\testline \newbox\testbox % \setbox\testbox\vbox{% Margin kerning is the adjustments of the characters at the margins of a typeset text. } \loop\ifvbox\testbox \setbox\testline=\vsplit\testbox to\baselineskip \unvbox\testline \setbox\testline=\lastbox \hbox to\hsize{\unhcopy\testline}% OK \hbox to\hsize{\unhbox\testline} % not OK \repeat \bye % -------------------------------------------------- Regards, Robert <w.m.l[at]gmx.net> ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-02-09 12:35 Message: Logged In: YES user_id=421 This has been fixed in 1.21a ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-01-31 23:34 Message: Logged In: YES user_id=929 There seems to be one place in hz.ch where \unhbox and \unhcopy are treated differently: %@x [1100] - margin kerning %while link(tail)<>null do tail:=link(tail); %@y %if c = copy_code then begin % while link(tail)<>null do tail:=link(tail); %end %else while link(tail) <> null do begin % r := link(tail); % if not is_char_node(r) and (type(r) = margin_kern_node) then begin % link(tail) := link(r); % free_avail(margin_char(r)); % free_node(r, margin_kern_node_size); % end; % tail:=link(tail); %end; %@z After just commenting this piece out (as shown), both \unhcopy and \unhbox do protrusion ok. Now i don't have the slightest idea what this code is for, neither which side effects would appear if it's removed... Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=274&group_id=106

1 0

[ pdftex-Bugs-199 ] font expansion: characters may vanish
by noreply＠sarovar.org 09 Feb '05

09 Feb '05

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: 2005-02-09 12:35 Message: Logged In: YES user_id=421 This has been fixed in 1.21a ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-01-31 13:08 Message: Logged In: YES user_id=421 The state of the patch is indeed fuzzy; at least I did not apply it, but some parts are in. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2005-01-31 02:59 Message: Logged In: NO It seems as if Hartmut's patch hasn't been applied, as the following test file will still produce incorrect output for both pdftex 1.20b and 1.20c-beta: %------------------------------------------------- \pdfadjustspacing=2 \font\testfont=cmr10 \testfont \pdffontexpand\font 0 1000 100 autoexpand \hsize40pt OK: text text text text\break not OK: text text text text\break \bye %------------------------------------------------- Regards, Robert <w.m.l[at]gmx.net> ---------------------------------------------------------------------- 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

feature request
by Hans Hagen 08 Feb '05

08 Feb '05

Hi, Some fonts have glyoh variants, e.g. latin modern has umlauts versions and alternative copyright symbols and such. The characteristics of those alternatives don't change, so we could pop them in using an special enc file, which is what i do now. However, in order to fully exploit this feature, we need some extension. Say that we use lmr10 two times, one time with the alternatives, and one time as-is. We need: - two tfm files (the same but a different name) - two mapping lines - one pfb file However, if we have \pdfsetfontenc\somefont{blabla.enc} we can do with - one tfm files (the same but a different name) - one mapping lines (the original) - one pfb file I can even imagine that we have \pdfsetfontfile\somefont{blabla.pfb} \pdfsetfontname\somefont{FunnyFontName} 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 -----------------------------------------------------------------

2 4

[ pdftex-Bugs-262 ] Type42 inclusion
by noreply＠sarovar.org 08 Feb '05

08 Feb '05

Bugs item #262, was opened at 2005-01-21 10:44 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=262&group_id=106 Category: Fonts Group: v1.20b >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Nobody (None) Assigned to: Hartmut Henkel (hhenkel) Summary: Type42 inclusion Initial Comment: Hello, Trying to get ttf fonts working both with dvips and pdflatex I experimented with converting the ttf to Type42 using fontforge, disassembling it via t1disasm and creating a pfb with t1asm. The resulting pfb is included via dvips and both ghostscript and distiller can interpret it. Unfortunately, pdflatex gives me the following error trying to include the pfb: Error: pdftex (file FranklinGothic-Medium.pfb): unexpected end of file ==> Fatal error occurred, the output PDF file is not finished! Cheers, Michael ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-02-08 10:30 Message: Logged In: YES user_id=421 This has been fixed in 1.21a ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-01-29 23:08 Message: Logged In: YES user_id=929 The attached simple patch for writet1.c checks the /FontType key and if it's 42, pdfTeX exits with an error message: Error: pdfetex (file ./foo.pfb): Type42 fonts unsupported by pdfTeX This could be modified so that an error is given if it's _not_ Type1.But which font types _are_ supported? Another way might be to check the header comment for "%!PS-AdobeFont" or "%!FontType1". But all this can be cheated, and there might be fonts with wrong comment lines floating around... Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-01-27 10:46 Message: Logged In: YES user_id=421 If we decide that Type42 fonts are unsupported, pdftex should at least raise a clear error when it finds them. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2005-01-27 10:14 Message: Logged In: YES user_id=710 Hi, pdftex doesn't support Type42 fonts and probably won't, unless someone else implements it, as I see little sense in making it work. Thanh ---------------------------------------------------------------------- Comment By: Michael Zedler (zedler) Date: 2005-01-22 14:36 Message: Logged In: YES user_id=2197 Hello, dvips also chokes if it tries to subset the font, including it completely works though. I don't really know if it's worth implementing support for Type42 in pdftex, I wouldn't use it either -- I just tried to find out if dvips+ttf without loss of hinting information is really a no-go as often claimed. Result was: no, no problem ;-) Cheers, Michael ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-01-21 23:13 Message: Logged In: YES user_id=929 >From inspection of disassembled font FranklinGothic-Medium.pfb it seems that this Type 42 font is incompatible with writet1.c.Maybe handling Type 42 fonts is not implemented in general? The problem is, that after scanning of the /Encoding array the function t1_subset_ascii_part() is waiting for the string "currentfile eexec" while running the {...} while (t1_in_eexec == 0); loop. But in the Type 42 font there follows the /sfnts key and the Type 42 program is scanned. Then, as t1_in_eexec will never be changed, the while loop runs into the end of the font file, resulting in the error. Looks like it would require quite some change in writet1.c to handle these Type 42 fonts. Would such a change make sense, given that this type of font appears rather seldomly? I also wonder how it should work in dvips, as it uses the same writet1.c, and here also the same error message appears. Also dvipdfm can't process the font, it just hangs. All on teTeX-2.99.9 debian woody i686. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Michael Zedler (zedler) Date: 2005-01-21 15:57 Message: Logged In: YES user_id=2197 You may find the pfb, tfm, vf at http://www.hft.ei.tum.de/mz/test_t42.zip I suppose the error is due to pdftex trying to subset the Type42 font. Cheers, Michael ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-01-21 10:58 Message: Logged In: YES user_id=421 Please include some test files; at least the pfb is needed. Also please login when commenting on this or any other bug. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=262&group_id=106

1 0

[ pdftex-Bugs-282 ] TTF embedding
by noreply＠sarovar.org 08 Feb '05

08 Feb '05

Bugs item #282, was opened at 2005-02-04 01:34 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=282&group_id=106 Category: Fonts Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: The Thanh Han (hanthethanh) Summary: TTF embedding Initial Comment: pdfeTeX 3.141592-1.20c-beta-20050203-2.2 (Web2C 7.5.4) Some TTF embedding problem, found when i tried the old test files from repaired bug 210. The log tells that chinese font htsong.ttf is embedded.But xpdf-3.0 chokes with Error: Couldn't create a font for 'MWCLGR+SongTi' Error: Couldn't create a font for 'ULNAVB+SongTi' Error: Couldn't create a font for 'FAKOEO+SongTi' and nothing is shown.Previously there were nice chinese characters. See tst.tgz. You also need free htsong.ttf, forgot from where, maybe google after it (it's huge, 9 MB). Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-02-08 10:30 Message: Logged In: YES user_id=421 This has been fixed in 1.21a ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=282&group_id=106

1 0

1.20c
by Martin Schröder 04 Feb '05

04 Feb '05

Hi, Thomas Esser is close to releasing teTeX 3.00 and asks for a new version of pdftex with all open bugs (!) fixed. Is there anything besides #242 and xpdf 3.00pl3 that should go in? 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

5 8

new snapshot
by The Thanh Han 04 Feb '05

04 Feb '05

Hi Martin & Hartmut, I uploaded a new snapshot of pdftex -- this version fixed the problem with ttf embedding and some minor fixes I forgot to apply in the previous version. To Hans: djgpp has also been updated. Thanh

1 0

Re: [NTG-pdftex] .TTF suffix is not supported by kpathsea?
by Akira Kakuto 04 Feb '05

04 Feb '05

> I have been playing with ttf2afm and somehow it cannot open files with > uppercase name (in the current dir). Renaming the file to have lowercase > suffix .ttf helps. Is this the correct behaviour of kpathsea, or I am > doing something wrong? That is the correct behavior. Kpse-allowed suffixes are .ttc and .ttf. -- Akira Kakuto

2 1

strange effect pdfliteral
by Hans Hagen 04 Feb '05

04 Feb '05

Can someone explain why in the last example the pdfliteral messes up the spacing \pdfcompresslevel=0 \setupcolors[state=start] \starttext \def\red #1{\pdfliteral {1 0 0 rg}#1\pdfliteral{0 g}} \def\green#1{\pdfliteral {0 1 0 rg}#1\pdfliteral{0 g}} \def\blue #1{\pdfliteral {0 0 1 rg}#1\pdfliteral{0 g}} \dorecurse{25} {\red{red} \green{green} \blue{blue} } \def\red #1{\pdfliteral direct {1 0 0 rg}#1\pdfliteral{0 g}} \def\green#1{\pdfliteral direct {0 1 0 rg}#1\pdfliteral{0 g}} \def\blue #1{\pdfliteral direct {0 0 1 rg}#1\pdfliteral{0 g}} \dorecurse{25} {\red{red} \green{green} \blue{blue} } \def\red #1{\pdfliteral direct {1 0 0 rg} #1\pdfliteral{0 g}} \def\green#1{\pdfliteral direct {0 1 0 rg} #1\pdfliteral{0 g}} \def\blue #1{\pdfliteral direct {0 0 1 rg} #1\pdfliteral{0 g}} \dorecurse{25} {\red{red} \green{green} \blue{blue} } \def\red #1{\pdfliteral direct {1 0 0 rg}#1\pdfliteral direct {0 g}} \def\green#1{\pdfliteral direct {0 1 0 rg}#1\pdfliteral direct {0 g}} \def\blue #1{\pdfliteral direct {0 0 1 rg}#1\pdfliteral direct {0 g}} \dorecurse{25} {\red{red} \green{green} \blue{blue} } \stoptext ----------------------------------------------------------------- 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 -----------------------------------------------------------------

2 1

.TTF suffix is not supported by kpathsea?
by The Thanh Han 04 Feb '05

04 Feb '05

Hi, I have been playing with ttf2afm and somehow it cannot open files with uppercase name (in the current dir). Renaming the file to have lowercase suffix .ttf helps. Is this the correct behaviour of kpathsea, or I am doing something wrong? Thanh

1 0

[ pdftex-Bugs-282 ] TTF embedding
by noreply＠sarovar.org 04 Feb '05

04 Feb '05

Bugs item #282, was opened at 2005-02-04 01:34 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=282&group_id=106 Category: Fonts Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: The Thanh Han (hanthethanh) Summary: TTF embedding Initial Comment: pdfeTeX 3.141592-1.20c-beta-20050203-2.2 (Web2C 7.5.4) Some TTF embedding problem, found when i tried the old test files from repaired bug 210. The log tells that chinese font htsong.ttf is embedded.But xpdf-3.0 chokes with Error: Couldn't create a font for 'MWCLGR+SongTi' Error: Couldn't create a font for 'ULNAVB+SongTi' Error: Couldn't create a font for 'FAKOEO+SongTi' and nothing is shown.Previously there were nice chinese characters. See tst.tgz. You also need free htsong.ttf, forgot from where, maybe google after it (it's huge, 9 MB). Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=282&group_id=106

1 0

forgot to apply patch to reject Type42 fonts
by The Thanh Han 03 Feb '05

03 Feb '05

Hi Martin, I forgot to apply the patch from Hartmut to reject Type42 fonts. Can you please apply it then? Thanks. Thanh

2 1

Type3 fonts
by The Thanh Han 03 Feb '05

03 Feb '05

Hi, I spent a few hours playing with type3 fonts, but was not able to create a type3 font that uses another font (type1). It seems that the text operators somehow doesn't work inside the CharProc stream for type3 fonts. I was experimenting with it because I wonder whether it makes sense to have mechanism to create user-defined fonts. The answer seems to be no. But anyway, if someone is interested in this issue, please have a look into the pdf I created, maybe I did something wrong. As the files are small so I attached it here, hopefully it doesn't cause any inconvenience. I tried with xpdf, gv and acrobat reader (on linux), and got dots or blank glyph only. In short, it seems that type3 font is not the way to go. Thanh

2 2

re: type 3
by Hans Hagen 03 Feb '05

03 Feb '05

Hi >> inconvenience. I tried with xpdf, gv and acrobat reader (on linux), and >> got dots or blank glyph only. with a bit of merging i can get something produced by metapost visible but only in gsview, changin gyour last part to: \pdfliteral direct {/F2 3009.9626 Tf} AA (i needed a bigger scale -) Is there an example of a file with a type3 that shows up somewhere? 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

[Fwd: Re: [NTG-pdftex] Type3 fonts]
by Hans Hagen 03 Feb '05

03 Feb '05

1 0

pdftex snapshot
by The Thanh Han 02 Feb '05

02 Feb '05

Hi, pdftex-1.20c-beta-20050202 is available at pdftex.sarovar.org/src This snapshot contains all patches from Hartmut and my changes. The djgpp binaries are also available. Thanh

1 0

on the bug "unhbox kills char protrusion"
by The Thanh Han 02 Feb '05

02 Feb '05

Hi, I was scratching my head for a while trying to remember why I wanted do remove margin_kern_node while unboxing. Then I found the following message: ,-------- | Date: Wed, 04 Oct 2000 19:45:49 +0200 | To: Han The Thanh <thanh(a)informatics.muni.cz> | From: Hans Hagen <pragma(a)wxs.nl> | Subject: Re: protruding -- an interesting problem | | At 07:35 PM 10/4/00 +0200, Han The Thanh wrote: | >Hans, | > | >I encoutered an interesting problem of protruding: they are implemented by | >inserting a new kind of node; I named it `margin_kern_node'. A problem | >arose when a paragraph broken into lines is now unboxed; we have some | >extra nodes which cannot be handled by other part of TeX anymore. I | >consider to ignore such nodes when unbox a box. | | Hm. What part? breaking apart boxes are a problem anyway, since marks and | specials interfere. I suggest: | | (1) keep the nodes there when unvboxing | (2) discard them when unhboxing (the lines of such an unvboxed box) | | There's a lot of stuff around that unvboxes, like multi column routines! I | would render your protruding useless. | | | if you have a margin_kern node, then can you also add: \nomarginkern (like | the proposes etex primitive \noligs) which means: don't kern the next char, | | Hans `-------- It is interesting to remove that part as Hartmut did, and see what surprises it can bring :). Thanh

1 0

[ pdftex-Bugs-274 ] \unhbox kills protrusion
by noreply＠sarovar.org 31 Jan '05

31 Jan '05

Bugs item #274, was opened at 2005-01-31 03:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=274&group_id=106 Category: hz Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: \unhbox kills protrusion Initial Comment: Protrusion will break when boxes containing protruded characters are \unhbox'ed. I've stumbled upon this when using edmac/ledmac, which decomposes each paragraph into lines, then reassembling them. I wasn't sure whether protrusion is supposed to survive this treatment but it does if one uses \unhcopy instead of \unhbox. Here's a greatly reduced example: %-------------------------------------------- \font\testfont=cmr10 \testfont \pdfprotrudechars=2 \rpcode\font`\-=1000 \parindent0pt \hsize=126pt \newbox\testline \newbox\testbox % \setbox\testbox\vbox{% Margin kerning is the adjustments of the characters at the margins of a typeset text. } \loop\ifvbox\testbox \setbox\testline=\vsplit\testbox to\baselineskip \unvbox\testline \setbox\testline=\lastbox \hbox to\hsize{\unhcopy\testline}% OK \hbox to\hsize{\unhbox\testline} % not OK \repeat \bye % -------------------------------------------------- Regards, Robert <w.m.l[at]gmx.net> ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-01-31 23:34 Message: Logged In: YES user_id=929 There seems to be one place in hz.ch where \unhbox and \unhcopy are treated differently: %@x [1100] - margin kerning %while link(tail)<>null do tail:=link(tail); %@y %if c = copy_code then begin % while link(tail)<>null do tail:=link(tail); %end %else while link(tail) <> null do begin % r := link(tail); % if not is_char_node(r) and (type(r) = margin_kern_node) then begin % link(tail) := link(r); % free_avail(margin_char(r)); % free_node(r, margin_kern_node_size); % end; % tail:=link(tail); %end; %@z After just commenting this piece out (as shown), both \unhcopy and \unhbox do protrusion ok. Now i don't have the slightest idea what this code is for, neither which side effects would appear if it's removed... Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=274&group_id=106

1 0

[ pdftex-Bugs-199 ] font expansion: characters may vanish
by noreply＠sarovar.org 31 Jan '05

31 Jan '05

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: Open 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: 2005-01-31 13:08 Message: Logged In: YES user_id=421 The state of the patch is indeed fuzzy; at least I did not apply it, but some parts are in. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2005-01-31 02:59 Message: Logged In: NO It seems as if Hartmut's patch hasn't been applied, as the following test file will still produce incorrect output for both pdftex 1.20b and 1.20c-beta: %------------------------------------------------- \pdfadjustspacing=2 \font\testfont=cmr10 \testfont \pdffontexpand\font 0 1000 100 autoexpand \hsize40pt OK: text text text text\break not OK: text text text text\break \bye %------------------------------------------------- Regards, Robert <w.m.l[at]gmx.net> ---------------------------------------------------------------------- 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-274 ] \unhbox kills protrusion
by noreply＠sarovar.org 31 Jan '05

31 Jan '05

Bugs item #274, was opened at 2005-01-31 02:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=274&group_id=106 Category: hz Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: The Thanh Han (hanthethanh) Summary: \unhbox kills protrusion Initial Comment: Protrusion will break when boxes containing protruded characters are \unhbox'ed. I've stumbled upon this when using edmac/ledmac, which decomposes each paragraph into lines, then reassembling them. I wasn't sure whether protrusion is supposed to survive this treatment but it does if one uses \unhcopy instead of \unhbox. Here's a greatly reduced example: %-------------------------------------------- \font\testfont=cmr10 \testfont \pdfprotrudechars=2 \rpcode\font`\-=1000 \parindent0pt \hsize=126pt \newbox\testline \newbox\testbox % \setbox\testbox\vbox{% Margin kerning is the adjustments of the characters at the margins of a typeset text. } \loop\ifvbox\testbox \setbox\testline=\vsplit\testbox to\baselineskip \unvbox\testline \setbox\testline=\lastbox \hbox to\hsize{\unhcopy\testline}% OK \hbox to\hsize{\unhbox\testline} % not OK \repeat \bye % -------------------------------------------------- Regards, Robert <w.m.l[at]gmx.net> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=274&group_id=106

1 0

[ pdftex-Bugs-199 ] font expansion: characters may vanish
by noreply＠sarovar.org 31 Jan '05

31 Jan '05

Bugs item #199, was opened at 2004-09-23 02:43 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: Nobody (None) Date: 2005-01-31 07:29 Message: Logged In: NO It seems as if Hartmut's patch hasn't been applied, as the following test file will still produce incorrect output for both pdftex 1.20b and 1.20c-beta: %------------------------------------------------- \pdfadjustspacing=2 \font\testfont=cmr10 \testfont \pdffontexpand\font 0 1000 100 autoexpand \hsize40pt OK: text text text text\break not OK: text text text text\break \bye %------------------------------------------------- Regards, Robert <w.m.l[at]gmx.net> ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-12-22 20:23 Message: Logged In: YES user_id=421 This has been fixed in 1.20b ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2004-10-02 00:11 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 20:47 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 03:36 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 20:57 Message: Logged In: YES user_id=421 An Acrobat Reader bug. :-) ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2004-09-23 03:32 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

crashing png graphic
by h h extern 30 Jan '05

30 Jan '05

3 2

[ pdftex-Bugs-262 ] Type42 inclusion
by noreply＠sarovar.org 29 Jan '05

29 Jan '05

Bugs item #262, was opened at 2005-01-21 10:44 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=262&group_id=106 Category: Fonts Group: v1.20b Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Hartmut Henkel (hhenkel) Summary: Type42 inclusion Initial Comment: Hello, Trying to get ttf fonts working both with dvips and pdflatex I experimented with converting the ttf to Type42 using fontforge, disassembling it via t1disasm and creating a pfb with t1asm. The resulting pfb is included via dvips and both ghostscript and distiller can interpret it. Unfortunately, pdflatex gives me the following error trying to include the pfb: Error: pdftex (file FranklinGothic-Medium.pfb): unexpected end of file ==> Fatal error occurred, the output PDF file is not finished! Cheers, Michael ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-01-29 23:08 Message: Logged In: YES user_id=929 The attached simple patch for writet1.c checks the /FontType key and if it's 42, pdfTeX exits with an error message: Error: pdfetex (file ./foo.pfb): Type42 fonts unsupported by pdfTeX This could be modified so that an error is given if it's _not_ Type1.But which font types _are_ supported? Another way might be to check the header comment for "%!PS-AdobeFont" or "%!FontType1". But all this can be cheated, and there might be fonts with wrong comment lines floating around... Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-01-27 10:46 Message: Logged In: YES user_id=421 If we decide that Type42 fonts are unsupported, pdftex should at least raise a clear error when it finds them. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2005-01-27 10:14 Message: Logged In: YES user_id=710 Hi, pdftex doesn't support Type42 fonts and probably won't, unless someone else implements it, as I see little sense in making it work. Thanh ---------------------------------------------------------------------- Comment By: Michael Zedler (zedler) Date: 2005-01-22 14:36 Message: Logged In: YES user_id=2197 Hello, dvips also chokes if it tries to subset the font, including it completely works though. I don't really know if it's worth implementing support for Type42 in pdftex, I wouldn't use it either -- I just tried to find out if dvips+ttf without loss of hinting information is really a no-go as often claimed. Result was: no, no problem ;-) Cheers, Michael ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-01-21 23:13 Message: Logged In: YES user_id=929 >From inspection of disassembled font FranklinGothic-Medium.pfb it seems that this Type 42 font is incompatible with writet1.c.Maybe handling Type 42 fonts is not implemented in general? The problem is, that after scanning of the /Encoding array the function t1_subset_ascii_part() is waiting for the string "currentfile eexec" while running the {...} while (t1_in_eexec == 0); loop. But in the Type 42 font there follows the /sfnts key and the Type 42 program is scanned. Then, as t1_in_eexec will never be changed, the while loop runs into the end of the font file, resulting in the error. Looks like it would require quite some change in writet1.c to handle these Type 42 fonts. Would such a change make sense, given that this type of font appears rather seldomly? I also wonder how it should work in dvips, as it uses the same writet1.c, and here also the same error message appears. Also dvipdfm can't process the font, it just hangs. All on teTeX-2.99.9 debian woody i686. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Michael Zedler (zedler) Date: 2005-01-21 15:57 Message: Logged In: YES user_id=2197 You may find the pfb, tfm, vf at http://www.hft.ei.tum.de/mz/test_t42.zip I suppose the error is due to pdftex trying to subset the Type42 font. Cheers, Michael ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-01-21 10:58 Message: Logged In: YES user_id=421 Please include some test files; at least the pfb is needed. Also please login when commenting on this or any other bug. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=262&group_id=106

1 0

[ pdftex-Patches-259 ] Expanded png inclusion support
by noreply＠sarovar.org 29 Jan '05

29 Jan '05

Patches item #259, was opened at 2005-01-11 16:44 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=259&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Nobody (None) Summary: Expanded png inclusion support Initial Comment: The attached zip file contains a change file for all pdftex's (to be applied *after* hz.cg) and a completely new writepng.c ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=259&group_id=106

4 3

Re: [pdftex] pdfeTeX: bad interaction of \pdfstartlink...\pdfendlink with \beginR...\endR
by The Thanh Han 28 Jan '05

28 Jan '05

Hi, I have no idea how to solve it. Perhaps someone with better understanding of etex internals can help? Thanh On Tue, Dec 28, 2004 at 11:51:40PM +0100, Hartmut Henkel wrote: > On Sun, 26 Dec 2004, Vladimir Volovich wrote: > > > There seems to be a bug in interaction of right-to-left features of > > eTeX with pdflink features of pdftex. > > yes, tried to localize it: When the horizontal list is reversed > (left/right swapped) by function reverse(), so are the \pdfstartlink and > \pdfendlink whatsits. Then \pdfendlink happens before \pdfstartlink, > causing the error. Tried to swap links from/to both nodes after > reversal, so that the start/end sequence is right, but then the 2nd > error appears: > > > This can't happen (copying). error: > > This seems to be due to a missing style_node: case in @ @<Case statement > to copy...@>= which might be result from some math node that is > artificially added during reversing the list or not? Copying also the > style_node makes it run. But no idea whether that's the right way to do > it. And there might be more cases like \pdfstartlink and \pdfendlink > that might need a fix. > > Regards, Hartmut > > _______________________________________________ > pdftex mailing list > pdftex(a)tug.org > http://tug.org/mailman/listinfo/pdftex >

1 0