- ntg-pdftex - NTG Mailing Lists

pdfTeX Manual Rev. 1.595, 20050422
by Hartmut Henkel 27 Apr '05

27 Apr '05

There is a fresh pdftex-t.tex manual version at sarovar with all new primitives for pdftex-1.21b (thanks to Taco!), and some streamlining. Regards, Hartmut

4 5

Re: various tiny 1.21b patches (fwd)
by Hartmut Henkel 21 Apr '05

21 Apr '05

---------- Forwarded message ---------- Date: Thu, 21 Apr 2005 07:46:00 +0200 (MEST) From: The Thanh Han <hanthethanh(a)gmx.net> To: Hartmut Henkel <hartmut_henkel(a)gmx.de> Subject: Re: various tiny 1.21b patches ...So until the end of this month I will have a chance to take a look at those changes. Can you please also post a mail to the ntg-pdftex ml saying that I am off-line for about 2 weeks. Many thanks. ... If nothing is urgent, can we postpone the release until I am back? Regards, Thanh Hartmut Henkel wrote: > Hi Thanh, > > attached find a bunch of diffs that should mainly tidy up left-over > stuff from the obsolete \pdfmovechars primitive. I hope i'm right that > also the update_enc() function is not needed anymore. > > The pdftex.ch.diff also contains a patch to get shorter names: > > \pdfoptionpdfimagehicolor --> > \pdfimagehicolor > > \pdfoptionimageapplygamma --> > \pdfimageapplygamma > > See ntg-pdftex list. I would then try to put the short names into the > pdftex manual. > > There were also left-over obsolete cfg_pdf12_compliant_code and > cfg_pdf13_compliant_code in pdftex.ch. > > Can you check and put these patches in before the release?

1 0

cmap inclusion and virtual fonts
by Michael Zedler 20 Apr '05

20 Apr '05

Hello, Concerning cmap inclusion and virtual fonts ftp://ftp.dante.de/tex-archive/macros/latex/contrib/cmap/README states "The main limitation currently is inability to work with virtual fonts, and this is because of limitation of pdftex, and may be resolved in a future versions of pdftex." Does this still hold? When using fonts with non-standard ligature names (e.g. /f_i, /f_l, /f_f etc with Adobe's current OTF) adding cmaps would be really useful - currently one cannot search for any word containing a ligature using Adobe Reader. Even better if these cmaps could be generated on the fly. Somehow Adobe Distiller manages to do so... Michael

1 0

length of new primitives
by Hartmut Henkel 20 Apr '05

20 Apr '05

while updating the manual, there are Taco's new primitives: \pdfimagegamma \pdfgamma and \pdfoptionpdfimagehicolor \pdfoptionimageapplygamma Trivial thing only: i wonder whether they really must be this long (there are already some very long ones, like (line break here) \pdfoptionpdfinclusionerrorlevel). Won't \pdfoptionpdfimagehicolor --> \pdfimagehicolor \pdfoptionimageapplygamma --> \pdfimageapplygamma serve as well? E. g. there is also \pdfadjustspacing, not \pdfoptionadjustspacing. BTW the new ones are not dumped into the format, so maybe one could say that only things with "option" would be dumped? Which are criteria that some stuff should be dumped, other not? Regards, Hartmut

2 1

bug 302
by The Thanh Han 12 Apr '05

12 Apr '05

Hi, as bug 302 doesn't seem to be pdftex specific, should the patch by Akira go to web2c? Regards, Thanh

3 2

[ pdftex-Feature Requests-89 ] Handle missing pages in included pdfs better
by noreply＠sarovar.org 12 Apr '05

12 Apr '05

Feature Requests item #89, was opened at 2004-07-08 14:38 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=89&group_id=106 Category: None Group: v1.21 Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) >Assigned to: Martin Schröder (oneiros) Summary: Handle missing pages in included pdfs better Initial Comment: Currently, when one tries to include page 10 of a 9 page document, pdftex quits. Proposed change: Behaviour of pdfTeX for pdf image inclusion: UNKNOWN := -1 Initialization: \pdflastximagepages := UNKNOWN Continue := Continue with empty xform object with dimension 1bp x 1bp. // 1bp because it avoids zero and possible problems and // the output is small (/BBox [0 0 1 1]) if PDFFileExists if PageNumber < 1 \pdflastximagepages = UNKNOWN Warning "Invalid page number" Continue elsif PageNumber > \pdflastximagepages \pdflastximagepages is set Warning "Page number to large (out of range) Continue else \pdflastximagepages is set image is included fi else Warning "PDF file does not exist" \pdflastximagepages = UNKNOWN Continue fi Failure/Success checking: if [page] < 1 * Page number too small elsif \pdflastximagepages = -1 * PDF file does not exist elsif [page] > \pdflastximagepages * Page number too large else * Success fi or with optimization for success: if [page] < 1 * Page number too small elsif [page] > \pdflastximagepages if \pdflastximagepages = -1 * PDF file does not exist else * Page number too large fi else * Success fi ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=89&group_id=106

1 0

[ pdftex-Feature Requests-254 ] fontexpansion, dvi output
by noreply＠sarovar.org 12 Apr '05

12 Apr '05

Feature Requests item #254, was opened at 2004-12-22 22:06 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: Rejected 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 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2005-01-14 03:19 Message: Logged In: YES user_id=710 It is likely that this will never be implemented. The better way to do that is to change the script \<TEX> (\<PDFTEX>) calls to create missing \<TFM> during run-time (on \<WEB2C>-based systems this is called |mktextfm|) to create all the required stuff on demand. Thanh ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=254&group_id=106

1 0

[ pdftex-Bugs-302 ] -jobname doesn't overcome texput
by noreply＠sarovar.org 12 Apr '05

12 Apr '05

Bugs item #302, was opened at 2005-03-01 19:06 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=302&group_id=106 >Category: web2c Group: v1.21a Status: Open Resolution: None Priority: 5 Submitted By: John Denker (jsd) >Assigned to: Olaf Weber (infovore) Summary: -jobname doesn't overcome texput Initial Comment: Hi -- Suppose I want to pipe commands into pdflatex: echo '\typeout{---\jobname---}' | \ pdflatex --jobname foo You might expect that to type out ---foo--- but instead it types out ---texput--- I observe that --jobname works just fine for any filename I can think of, just not when the filename is absent entirely. I can offer two workarounds: 1) It's not documented, but nevertheless possible to \def\jobname{foo}. 2) Of course it's possible to stuff the commands into tmp.tex and then pdflatex --jobname foo tmp.tex Because these workarounds exist, I would rate this as a very low-priority bug. But it had me surprised and confused for a while. Given the overall high quality of the product, I thought I'd bring it to your attention. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2005-04-12 14:11 Message: Logged In: YES user_id=421 Patches provided by Akira on NTG-pdftex ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=302&group_id=106

1 0

Re: [NTG-pdftex] -jobname doesn't overcome texput
by Akira Kakuto 12 Apr '05

12 Apr '05

> > --- texmfmp.c.orig Tue Dec 21 20:33:56 2004 > > +++ texmfmp.c Mon Apr 04 23:17:20 2005 > > @@ -1599,6 +1599,7 @@ > > getjobname() > > { > > strnumber ret = curname; > > + if (ret == 0) ret = maketexstring("texput"); > > if (job_name != NULL) > > ret = maketexstring(job_name); > > return ret; > > --- texmfmp.c.orig Tue Dec 21 20:33:56 2004 > +++ texmfmp.c Tue Apr 05 00:09:40 2005 > @@ -1595,10 +1595,19 @@ > return maketexstring(fullnameoffile); > } > > +#if defined (MF) > +#define DEFAULTJOBNAME "mfput" > +#elif defined (MP) > +#define DEFAULTJOBNAME "mpout" > +#else > +#define DEFAULTJOBNAME "texput" > +#endif > + > strnumber > getjobname() > { > strnumber ret = curname; > + if (ret == 0) ret = maketexstring(DEFAULTJOBNAME); > if (job_name != NULL) > ret = maketexstring(job_name); > return ret; mpost seems to require somewhat different texmfmp.c: --- texmfmp.c.orig Tue Dec 21 20:33:56 2004 +++ texmfmp.c Tue Apr 12 21:02:22 2005 @@ -1595,10 +1595,22 @@ return maketexstring(fullnameoffile); } +#if defined (MF) +#define DEFAULTJOBNAME "mfput" +#elif defined (MP) +#define DEFAULTJOBNAME "mpout" +#else +#define DEFAULTJOBNAME "texput" +#endif + strnumber getjobname() { strnumber ret = curname; + if (ret == 0) ret = maketexstring(DEFAULTJOBNAME); +#if defined (MP) + if (jobname == 0) ret = maketexstring(DEFAULTJOBNAME); +#endif if (job_name != NULL) ret = maketexstring(job_name); return ret; Best regards, Akira

1 0

margin kerning and unhboxing
by The Thanh Han 11 Apr '05

11 Apr '05

Hi, there were some problems to make margin kerning work with unhbox/unhcopy. After some discussions with Harmut we have come to a solution: we shall drop margin kerns while unboxing. People who wish to use margin kerning with unhboxing are out of luck. Sorry, but we think it is too much work and too risky to make it work. We also introduced a workaround: now we have 2 new primitives \leftmarginkern and \righmarginkern, which allows access to margin kerns of a hbox. Usage (tested): ,-------- | \newbox\testline | | ... | | \dimen0=\leftmarginkern \testline pt | \dimen1=\rightmarginkern \testline pt | \line{\kern\dimen0\unhcopy\testline\kern\dimen1} `-------- this feature will be available in the next bug-fix release (should come out soon). Thanh

1 0

protrusion when?
by Hartmut Henkel 09 Apr '05

09 Apr '05

Currently a character is protruded if its rpcode/lpcode is set and it can be reached from the margin by skipping skippable items. These items are various kerns, glues, empty boxes etc. always with width 0pt. Maybe this could be extended by adding up the horizontal movements of non-zero kerns, non-stretchable glues etc. and when a protrudable character is reached and the total movement to there would be 0pt, the character would still be protruded. E. g. protrusion could happen after a \kern1sp\kern-1sp pair or after \kern1sp\hskip-1sp. Would this make sense? E. g. Robert told that (cancelling?) kerns are sometimes used as markers... Or, what if one would completely ignore/skip over all invisible items (kerns, non-stretchable glues, even with width != 0pt) and would just shift the first protrudable character? This would mean, that indented characters would be also protruded relative to indentation. Regards, Hartmut

5 7

Re: [NTG-pdftex] -jobname doesn't overcome texput
by Akira Kakuto 04 Apr '05

04 Apr '05

> --- texmfmp.c.orig Tue Dec 21 20:33:56 2004 > +++ texmfmp.c Mon Apr 04 23:17:20 2005 > @@ -1599,6 +1599,7 @@ > getjobname() > { > strnumber ret = curname; > + if (ret == 0) ret = maketexstring("texput"); > if (job_name != NULL) > ret = maketexstring(job_name); > return ret; --- texmfmp.c.orig Tue Dec 21 20:33:56 2004 +++ texmfmp.c Tue Apr 05 00:09:40 2005 @@ -1595,10 +1595,19 @@ return maketexstring(fullnameoffile); } +#if defined (MF) +#define DEFAULTJOBNAME "mfput" +#elif defined (MP) +#define DEFAULTJOBNAME "mpout" +#else +#define DEFAULTJOBNAME "texput" +#endif + strnumber getjobname() { strnumber ret = curname; + if (ret == 0) ret = maketexstring(DEFAULTJOBNAME); if (job_name != NULL) ret = maketexstring(job_name); return ret; changes like in tex.ch are also necessary in mf.ch, mp.ch, com16bit.ch and com16bit-rc2.ch (for aleph). Best regards, Akira

1 0

Re: [NTG-pdftex] -jobname doesn't overcome texput
by Akira Kakuto 04 Apr '05

04 Apr '05

>the bug report below seems to be a more general thing, affecting also e. >g. tex. Maybe it's something for Olaf? --- tex.ch.orig Thu Dec 30 00:07:46 2004 +++ tex.ch Mon Apr 04 23:15:59 2005 @@ -2242,8 +2242,10 @@ @z @x [29.534] l.10289 - Filename change for the recorder. +if job_name=0 then job_name:="texput"; @.texput@> @y +if job_name=0 then job_name:=get_job_name; @.texput@> pack_job_name(".fls"); recorder_change_filename(stringcast(name_of_file+1)); --- texmfmp.c.orig Tue Dec 21 20:33:56 2004 +++ texmfmp.c Mon Apr 04 23:17:20 2005 @@ -1599,6 +1599,7 @@ getjobname() { strnumber ret = curname; + if (ret == 0) ret = maketexstring("texput"); if (job_name != NULL) ret = maketexstring(job_name); return ret; Best regards, Akira

1 0

[ pdftex-Bugs-302 ] -jobname doesn't overcome texput
by noreply＠sarovar.org 03 Apr '05

03 Apr '05

Bugs item #302, was opened at 2005-03-01 13:06 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=302&group_id=106 Category: None Group: v1.21a Status: Open Resolution: None Priority: 5 Submitted By: John Denker (jsd) Assigned to: Nobody (None) Summary: -jobname doesn't overcome texput Initial Comment: Hi -- Suppose I want to pipe commands into pdflatex: echo '\typeout{---\jobname---}' | \ pdflatex --jobname foo You might expect that to type out ---foo--- but instead it types out ---texput--- I observe that --jobname works just fine for any filename I can think of, just not when the filename is absent entirely. I can offer two workarounds: 1) It's not documented, but nevertheless possible to \def\jobname{foo}. 2) Of course it's possible to stuff the commands into tmp.tex and then pdflatex --jobname foo tmp.tex Because these workarounds exist, I would rate this as a very low-priority bug. But it had me surprised and confused for a while. Given the overall high quality of the product, I thought I'd bring it to your attention. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=302&group_id=106

2 1

[ pdftex-Bugs-292 ] protuding leads to "This can't happen (paragraph)."
by noreply＠sarovar.org 03 Apr '05

03 Apr '05

Bugs item #292, was opened at 2005-02-14 15:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=292&group_id=106 Category: hz Group: v1.21a Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) >Summary: protuding leads to "This can't happen (paragraph)." Initial Comment: The input --------------------- \pdfoutput=1 \input edmac \input protcode \font\eightrm=ptmr8t \setprotcode\eightrm \pdfprotrudechars=2 \linenummargin{outer} %% left|right|inner|outer \footparagraph{A} \tracingall\tracingonline=0 \beginnumbering \pstart \text{There}\Afootnote{Habent sua fata libelli. (Der Satz wurde auf Wunsch der Redaktion von »Living Marxism« gestrichen; siehe Korsch an P.~Mattick am 3.10.1938.)}/ is a striking contrast between the impression produced in the minds of West"=European revolutionaries by those short pamphlets of Lenin and Trotsky which appeared in poorly translated and poorly printed editions during the final stage and the aftermath of the war, and the response called forth in Europe and U.S.A. by the belated appearance, in 1927, of the first extra"=Russian versions of Lenin's philosophical work of 1908, on »Materialism and Empirio"=Criticism«. \pend \endnumbering \bye --------------------- (all input files are in the attached archive) leads to --------------------- ! This can't happen (paragraph). <recently read> \par \do@feet ...s \else \Afootstart {A}\Afootgroup {A} \fi \ifvoid \Bfootins \els... \pagecontents ...p \@cclv \unvbox \@cclv \do@feet \ifr@ggedbottom \kern -\di... \pagebody ...\boxmaxdepth \maxdepth \pagecontents } \edmac@output ...e \vbox {\makeheadline \pagebody \makefootline }\fi }\advan... <output> {\edmac@output } ... l.30 \bye I'm broken. Please show this to someone who can fix can fix --------------------- ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-04-03 21:00 Message: Logged In: YES user_id=929 P.S. A nice test are the various ledmac test files in directory texmf-dist/doc/latex/ledmac/, when you add the microtype package (somebody must have provided such a directory to me, thanks)... Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-04-03 20:26 Message: Logged In: YES user_id=929 New try of a patch, see patch-292b.tgz. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-03-23 15:43 Message: Logged In: YES user_id=421 Hartmut, what's the status here? I remember you fixed this somehow at EuroTeX. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-02-14 20:42 Message: Logged In: YES user_id=929 Now we know which side effects patch-274 has. When it's reverted, the file is processed without error, but margin kerning is missing (which was the original problem before patch-274). Following experiment is done _with_ patch-274. The "this can't happen" error happens within the line_break routine, which chokes on a margin_kern_node (which was filtered out before patch-274).If one adds margin_kern_node to the do_nothing list, like: mark_node,ins_node,adjust_node,margin_kern_node: do_nothing; othercases confusion("paragraph") it apparently works ok, and margin kerning is fine also (requires patch in hz.ch). But i need to understand how the line_break routine works, whether a do_nothing is the right thing to do... Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-02-14 15:30 Message: Logged In: YES user_id=421 The submitter used the attached edmac.doc; the error is the same. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=292&group_id=106

1 0

[ pdftex-Bugs-292 ] protuding leads to "This can't happen (paragraph)."
by noreply＠sarovar.org 03 Apr '05

03 Apr '05

Bugs item #292, was opened at 2005-02-14 15:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=292&group_id=106 Category: hz Group: v1.21a Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Hartmut Henkel (hhenkel) >Summary: protuding leads to "This can't happen (paragraph)." Initial Comment: The input --------------------- \pdfoutput=1 \input edmac \input protcode \font\eightrm=ptmr8t \setprotcode\eightrm \pdfprotrudechars=2 \linenummargin{outer} %% left|right|inner|outer \footparagraph{A} \tracingall\tracingonline=0 \beginnumbering \pstart \text{There}\Afootnote{Habent sua fata libelli. (Der Satz wurde auf Wunsch der Redaktion von »Living Marxism« gestrichen; siehe Korsch an P.~Mattick am 3.10.1938.)}/ is a striking contrast between the impression produced in the minds of West"=European revolutionaries by those short pamphlets of Lenin and Trotsky which appeared in poorly translated and poorly printed editions during the final stage and the aftermath of the war, and the response called forth in Europe and U.S.A. by the belated appearance, in 1927, of the first extra"=Russian versions of Lenin's philosophical work of 1908, on »Materialism and Empirio"=Criticism«. \pend \endnumbering \bye --------------------- (all input files are in the attached archive) leads to --------------------- ! This can't happen (paragraph). <recently read> \par \do@feet ...s \else \Afootstart {A}\Afootgroup {A} \fi \ifvoid \Bfootins \els... \pagecontents ...p \@cclv \unvbox \@cclv \do@feet \ifr@ggedbottom \kern -\di... \pagebody ...\boxmaxdepth \maxdepth \pagecontents } \edmac@output ...e \vbox {\makeheadline \pagebody \makefootline }\fi }\advan... <output> {\edmac@output } ... l.30 \bye I'm broken. Please show this to someone who can fix can fix --------------------- ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-04-03 20:26 Message: Logged In: YES user_id=929 New try of a patch, see patch-292b.tgz. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-03-23 15:43 Message: Logged In: YES user_id=421 Hartmut, what's the status here? I remember you fixed this somehow at EuroTeX. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-02-14 20:42 Message: Logged In: YES user_id=929 Now we know which side effects patch-274 has. When it's reverted, the file is processed without error, but margin kerning is missing (which was the original problem before patch-274). Following experiment is done _with_ patch-274. The "this can't happen" error happens within the line_break routine, which chokes on a margin_kern_node (which was filtered out before patch-274).If one adds margin_kern_node to the do_nothing list, like: mark_node,ins_node,adjust_node,margin_kern_node: do_nothing; othercases confusion("paragraph") it apparently works ok, and margin kerning is fine also (requires patch in hz.ch). But i need to understand how the line_break routine works, whether a do_nothing is the right thing to do... Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-02-14 15:30 Message: Logged In: YES user_id=421 The submitter used the attached edmac.doc; the error is the same. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=292&group_id=106

1 0

[ pdftex-Bugs-294 ] pdfmovechars/encoding problem
by noreply＠sarovar.org 02 Apr '05

02 Apr '05

Bugs item #294, was opened at 2005-02-15 21:06 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=294&group_id=106 Category: Fonts Group: v1.21a Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: The Thanh Han (hanthethanh) Summary: pdfmovechars/encoding problem Initial Comment: This has been reported by Jörg Heinrich at 1 Feb. 2005 on the pdftex list (Subject: [pdftex] pdfetex). The following derived example leads to a segfault: % this works: %\pdfmovechars=1 % this gives segfault: \pdfmovechars=2 % this works: %\pdfmapline{phvr8r Helvetica <8r.enc <phvr8a.pfb} % this gives segfault: \pdfmapline{phvr8r Helvetica <phvr8a.pfb} \font\phv phvr8r at 10pt \phv a \bye ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-04-02 00:53 Message: Logged In: YES user_id=929 This patch (patch-294b.tgz) removes the functionality of the \pdfmovechars primitive. What remains for now is a warning, once per run, if \pdfmovechars is set to a value unequal 0: ! pdfTeX warning: Primitive \pdfmovechars is obsolete. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-31 23:57 Message: Logged In: YES user_id=929 In function t1_read_enc() the function t1_prefix() was called while t1_line_array was not allocated yet, causing the segfault. Making a do...while loop from the while loop does allocation via t1_getline() in time, see the patch. Maybe that's enough for now to close the bug. It seems that the function t1_read_enc() is anyway called only via get_enc() when pdfmovechars > 0, so both functions serve only this special case, and are normally not in use. I have done not any check whether \pdfmovechars general functionality is ok, and one might as well thow out this primitive, and the unneeded functions. Let's add a note "deprecated" in the manual... Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=294&group_id=106

1 0

[ pdftex-Bugs-294 ] pdfmovechars/encoding problem
by noreply＠sarovar.org 01 Apr '05

01 Apr '05

Bugs item #294, was opened at 2005-02-15 21:06 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=294&group_id=106 Category: Fonts Group: v1.21a Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: The Thanh Han (hanthethanh) Summary: pdfmovechars/encoding problem Initial Comment: This has been reported by Jörg Heinrich at 1 Feb. 2005 on the pdftex list (Subject: [pdftex] pdfetex). The following derived example leads to a segfault: % this works: %\pdfmovechars=1 % this gives segfault: \pdfmovechars=2 % this works: %\pdfmapline{phvr8r Helvetica <8r.enc <phvr8a.pfb} % this gives segfault: \pdfmapline{phvr8r Helvetica <phvr8a.pfb} \font\phv phvr8r at 10pt \phv a \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=294&group_id=106

5 4

[ pdftex-Bugs-294 ] pdfmovechars/encoding problem
by noreply＠sarovar.org 31 Mar '05

31 Mar '05

Bugs item #294, was opened at 2005-02-15 21:06 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=294&group_id=106 Category: Fonts Group: v1.21a Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: The Thanh Han (hanthethanh) Summary: pdfmovechars/encoding problem Initial Comment: This has been reported by Jörg Heinrich at 1 Feb. 2005 on the pdftex list (Subject: [pdftex] pdfetex). The following derived example leads to a segfault: % this works: %\pdfmovechars=1 % this gives segfault: \pdfmovechars=2 % this works: %\pdfmapline{phvr8r Helvetica <8r.enc <phvr8a.pfb} % this gives segfault: \pdfmapline{phvr8r Helvetica <phvr8a.pfb} \font\phv phvr8r at 10pt \phv a \bye ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-31 23:57 Message: Logged In: YES user_id=929 In function t1_read_enc() the function t1_prefix() was called while t1_line_array was not allocated yet, causing the segfault. Making a do...while loop from the while loop does allocation via t1_getline() in time, see the patch. Maybe that's enough for now to close the bug. It seems that the function t1_read_enc() is anyway called only via get_enc() when pdfmovechars > 0, so both functions serve only this special case, and are normally not in use. I have done not any check whether \pdfmovechars general functionality is ok, and one might as well thow out this primitive, and the unneeded functions. Let's add a note "deprecated" in the manual... Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=294&group_id=106

1 0

[Fwd: Re: [NTG-pdftex] [ pdftex-Bugs-294 ] pdfmovechars/encoding problem]
by Hans Hagen 31 Mar '05

31 Mar '05

1 0

[ pdftex-Bugs-304 ] Names of expanded fonts not in log output
by noreply＠sarovar.org 30 Mar '05

30 Mar '05

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: None 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: 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-320 ] \textcolor
by noreply＠sarovar.org 28 Mar '05

28 Mar '05

Bugs item #320, was opened at 2005-03-28 03:52 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=320&group_id=106 Category: None Group: v1.21a Status: Open Resolution: None Priority: 5 Submitted By: Aleks Kleyn (aleks_kleyn) Assigned to: Nobody (None) Summary: \textcolor Initial Comment: I want to change color of text using comand \textcolor {blue}. However when text flows from one page to another the color resets to standard on the next page. Initially I beleived that this problem of pdf. However I tried today latex.exe and then converted dvi to pdf. I got effect that I expected: text had on both pages the same color. However using of pdflatex is more better because it prepares bookmarks for pdf. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=320&group_id=106

1 0

[ pdftex-Bugs-315 ] pdflatex on solaris font problems with acroread
by noreply＠sarovar.org 24 Mar '05

24 Mar '05

Bugs item #315, was opened at 2005-03-21 10:53 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=315&group_id=106 Category: Fonts Group: v1.21a Status: Open Resolution: Fixed Priority: 5 Submitted By: Stan Swiercz (swiercz) Assigned to: Martin Schröder (oneiros) Summary: pdflatex on solaris font problems with acroread Initial Comment: I have compiled pdflatex 1.2.1a that comes with teTeX 3.0 on both linux and solaris. The linux version works properly but the solaris one does not. The last font included in the pdf output produces the error: Unable to extract the embedded font 'KTGBVU+CMR8'. Some characters may not display or print correctly. when viewed with acroread (version 5 or 6, windows, linux and solaris versions). Note that no error is seen when viewed with ghostscript and xpdf. The above error comes from the file: ------------------------ \documentclass{article} \newcommand{\ip}[2]{(#1, #2)} \begin{document} This is an example input file. Footnotes \footnote{This is an example of a footnote.} pose no problem. \LaTeX\ is good at typesetting mathematical formulas like $ x-3y + z = 7 $ or $ a_{1} > x^{2n} + y^{2n} > x' $ or $ \ip{A}{B} = \sum_{i} a_{i} b_{i} $. The spaces you type in a formula are ignored. Remember that a letter like $x$ % $ ... $ and $ ... $ are equivalent is a formula when it denotes a mathematical symbol, and it should be typed as one. \end{document} ----------------------- The sigma is produced correctly. If however I comment out the footnote, the sigma in the summation is no longer viewable and the error message is Unable to extract the embedded font 'ATSTIO+CMEX10'. Some characters may not display or print correctly. I attach a pdf files produced on solaris. Is this a know problem with a patch available? If you need further information please do not hesitate to contact me. Stan ---------------------------------------------------------------------- >Comment By: Stan Swiercz (swiercz) Date: 2005-03-24 14:44 Message: Logged In: YES user_id=2345 I restored the original ptexmac.h and patched writet1.c and recompiled on the original solaris system I was compiling on. The pdf produced displays properly on acroread. I thank you for the prompt response and help. Stan ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-24 14:29 Message: Logged In: YES user_id=929 Hi Stan, if possible please test the attached patch to writet1.c. This now really initializes t1_save_offset to zero, and the save_offset() calls are only where really needed (there were too many, too early. They must never come before the first fb_putchar(), as only this does the alloc_array(fb,...) initialization. Also please do _not_ patch ptexmac.h (!), as this patch would cover otherwise maybe missing initializations. Leave ptexmac.h as in teTeX-3.0. I tried the writet1.c patch with arbitrary initial value of fb_ptr, and it seems to get it right. Thanks a lot for help! Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-24 10:48 Message: Logged In: YES user_id=929 who is pulling this bug into the "closed area"? :-) It seems to work but it still looks weird, maybe the final patch will be different... Regards, Hartmut ---------------------------------------------------------------------- Comment By: Stan Swiercz (swiercz) Date: 2005-03-24 10:18 Message: Logged In: YES user_id=2345 The ptexmac.h patch fixed it. Thank you! Stan ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-24 10:04 Message: Logged In: YES user_id=929 once again, please try the patch for ptexmac.h. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Stan Swiercz (swiercz) Date: 2005-03-24 10:01 Message: Logged In: YES user_id=2345 It does appear that t1_offset_value is at fault. I put in a pdftex_warn (something easy to add) in writet1.c and the first time it outputs I see Warning: pdflatex (file /nfs/encs/ArchDep/sun4.solaris8/pkg/teTeX-3.0/root/texm f/fonts/type1/bluesky/cm/cmr8.pfb): -268435455 t1_save_offset value All the other times the "warning" is displayed it returns 0. Stan ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-24 09:52 Message: Logged In: YES user_id=929 thanks a lot, it was as expected :-( but the error _is_ around there, it's uninitialized fb_ptr i guess, just searching how to initialize it. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Stan Swiercz (swiercz) Date: 2005-03-24 09:44 Message: Logged In: YES user_id=2345 I have applied the patch and found no difference. Stan ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-24 09:29 Message: Logged In: YES user_id=929 maybe the infamous "Solaris compiler bug" is just an uninitialized variable t1_save_offset? It's unclear, as it seems that this could happen only if the font is not being included. Anyway: Could some Solaris freak try out the attached tiny patch to writet1.c? Regards, Hartmut ---------------------------------------------------------------------- Comment By: Thomas Esser (tetex) Date: 2005-03-23 19:35 Message: Logged In: YES user_id=1230 We have seen this before. pdftex list, posting by Adrian Lanz, Mon, 09 Aug 2004. There was no real outcome of that thread. Adrian wrote on 23 Sep 2004 to the texlive list: > On Tue, Sep 21, 2004 at 07:18:23PM -0500, Maksym Polyakov wrote: >> apparently there was some overflow in /Length1 -- it should be 810 > > Ah, now it sounds familiar. Adrian Lanz has reported the same to > pdftex(a)tug.org (09 Aug 2004, he uses SUN Solaris 9 / gcc 3.3.2). > Yes, I had exactly the same problem recently installing teTeX-beta 2.96.7.20040721. In my case, the symptom was that pdflatex run without error, but a wrong /Length1 parameter was inserted in the PDF output file, which evidently caused Acrobat Reader's error message (no problem, however, with xpdf or with the "dvips -Ppdf" routine). I think I solved the problem by changing the order and rules how shared libraries are found and handled on my Sun Sparc Solaris 2.9 system, and/or I may have re-installed some programs and libraries (ncurses, gettext, libiconv). I am sorry not being more specific on So, we have at least three people with this problem: Stan Swiercz, Maksym Polyakov, Adrian Lanz. I think that this is some king of compiler bug or something like that... Thomas ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-03-23 09:42 Message: Logged In: YES user_id=421 Yes, this is definitely a problem for some specific solaris installations which I can't reproduce. ---------------------------------------------------------------------- Comment By: Stan Swiercz (swiercz) Date: 2005-03-23 09:08 Message: Logged In: YES user_id=2345 I have done more debugging and I find that with a newer solaris 9 kernel the executable works fine. There is some patch to the OS that fixes this. This is something static as when I run this executable on a solaris machine running an older solaris9 kernel or solaris8 it works properly. Further digging I find that when I run the linker command on the older solaris 9 machine it produces a faulty executable BUT if I run "g++ -v" to see what the real linking command is and cut and paste it so as to run it instead the executable produces a pdf viewable with acroread. The basic g++ link command is c++ -o pdfetex pdfetexini.o pdfetex0.o pdfetex1.o pdfetex2.o pdfetex3.o pdfetexextra.o ../../libs/md5/md5.o pdftexdir/libpdf.a ../../libs/libpng/libpng.a ../../libs/zlib/libz.a ../../libs/xpdf/xpdf/libxpdf.a ../../libs/xpdf/goo/libGoo.a ../../libs/xpdf/fofi/libfofi.a -lsocket lib/lib.a ../kpathsea/.libs/libkpathsea.a -lm Instead of running this on older kernels I used /encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/collect2 -V -Y P,/usr/ccs/lib:/usr/lib -L /local/lib -L /encs/lib -Qy -o pdfetex /encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/crt1.o /encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/crti.o /usr/ccs/lib/values-Xa.o /encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/crtbegin.o -L/encs/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3.2 -L/encs/bin/../lib/gcc-lib -L/encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2 -L/usr/ccs/bin -L/usr/ccs/lib -L/encs/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../.. -L/encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../.. pdfetexini.o pdfetex0.o pdfetex1.o pdfetex2.o pdfetex3.o pdfetexextra.o ../../libs/md5/md5.o pdftexdir/libpdf.a ../../libs/libpng/libpng.a ../../libs/zlib/libz.a ../../libs/xpdf/xpdf/libxpdf.a ../../libs/xpdf/goo/libGoo.a ../../libs/xpdf/fofi/libfofi.a -lsocket lib/lib.a ../kpathsea/.libs/libkpathsea.a -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc -lc /encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/crtend.o /encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/crtn.o For the record /usr/ccs/lib/values-Xa.o is the same on both systems. I don't understrand... I also tracked down what the difference was between a pdf file that displays and does not display. The one that does display correctly has /Type /Page /Contents 49 0 R /Resources 47 0 R /MediaBox [0 0 612 792] /Parent 25 0 R >> endobj 47 0 obj <> /ProcSet [ /PDF /Text ] >> endobj 45 0 obj << /Length1 946 /Length2 3204 /Length3 532 /Length 3847 /Filter /FlateDecode while the one that does not has /Type /Page /Contents 49 0 R /Resources 47 0 R /MediaBox [0 0 612 792] /Parent 25 0 R >> endobj 47 0 obj <> /ProcSet [ /PDF /Text ] >> endobj 45 0 obj << /Length1 268436401 /Length2 3204 /Length3 532 /Length 3848 /Filter /FlateDecode the 946 has turned into 268436401! Hope this info helps. Stan ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-03-23 08:25 Message: Logged In: YES user_id=421 This seems to be a build problem on Solaris. Compiling the example on teTeX 3.0 on Linux produces a pdf that shows no problems in AR. A possible cause for the message by AR might be this extract from pdf_test_solaris.pdf: --------- 29 0 obj << /Length1 268436401 /Length2 3204 --------- Length1 is definitely wrong. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-03-23 08:16 Message: Logged In: YES user_id=421 I can reproduce the problem with AR5 and AR7(latest "beta") on Linux. I can't reproduce it with gs 8.50 and Jaws. I suspect that this is a bug in AR. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=315&group_id=106

1 0

[ pdftex-Bugs-315 ] pdflatex on solaris font problems with acroread
by noreply＠sarovar.org 24 Mar '05

24 Mar '05

Bugs item #315, was opened at 2005-03-21 16:53 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=315&group_id=106 Category: Fonts Group: v1.21a Status: Open Resolution: Fixed Priority: 5 Submitted By: Stan Swiercz (swiercz) Assigned to: Martin Schröder (oneiros) Summary: pdflatex on solaris font problems with acroread Initial Comment: I have compiled pdflatex 1.2.1a that comes with teTeX 3.0 on both linux and solaris. The linux version works properly but the solaris one does not. The last font included in the pdf output produces the error: Unable to extract the embedded font 'KTGBVU+CMR8'. Some characters may not display or print correctly. when viewed with acroread (version 5 or 6, windows, linux and solaris versions). Note that no error is seen when viewed with ghostscript and xpdf. The above error comes from the file: ------------------------ \documentclass{article} \newcommand{\ip}[2]{(#1, #2)} \begin{document} This is an example input file. Footnotes \footnote{This is an example of a footnote.} pose no problem. \LaTeX\ is good at typesetting mathematical formulas like $ x-3y + z = 7 $ or $ a_{1} > x^{2n} + y^{2n} > x' $ or $ \ip{A}{B} = \sum_{i} a_{i} b_{i} $. The spaces you type in a formula are ignored. Remember that a letter like $x$ % $ ... $ and $ ... $ are equivalent is a formula when it denotes a mathematical symbol, and it should be typed as one. \end{document} ----------------------- The sigma is produced correctly. If however I comment out the footnote, the sigma in the summation is no longer viewable and the error message is Unable to extract the embedded font 'ATSTIO+CMEX10'. Some characters may not display or print correctly. I attach a pdf files produced on solaris. Is this a know problem with a patch available? If you need further information please do not hesitate to contact me. Stan ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-24 20:29 Message: Logged In: YES user_id=929 Hi Stan, if possible please test the attached patch to writet1.c. This now really initializes t1_save_offset to zero, and the save_offset() calls are only where really needed (there were too many, too early. They must never come before the first fb_putchar(), as only this does the alloc_array(fb,...) initialization. Also please do _not_ patch ptexmac.h (!), as this patch would cover otherwise maybe missing initializations. Leave ptexmac.h as in teTeX-3.0. I tried the writet1.c patch with arbitrary initial value of fb_ptr, and it seems to get it right. Thanks a lot for help! Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-24 16:48 Message: Logged In: YES user_id=929 who is pulling this bug into the "closed area"? :-) It seems to work but it still looks weird, maybe the final patch will be different... Regards, Hartmut ---------------------------------------------------------------------- Comment By: Stan Swiercz (swiercz) Date: 2005-03-24 16:18 Message: Logged In: YES user_id=2345 The ptexmac.h patch fixed it. Thank you! Stan ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-24 16:04 Message: Logged In: YES user_id=929 once again, please try the patch for ptexmac.h. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Stan Swiercz (swiercz) Date: 2005-03-24 16:01 Message: Logged In: YES user_id=2345 It does appear that t1_offset_value is at fault. I put in a pdftex_warn (something easy to add) in writet1.c and the first time it outputs I see Warning: pdflatex (file /nfs/encs/ArchDep/sun4.solaris8/pkg/teTeX-3.0/root/texm f/fonts/type1/bluesky/cm/cmr8.pfb): -268435455 t1_save_offset value All the other times the "warning" is displayed it returns 0. Stan ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-24 15:52 Message: Logged In: YES user_id=929 thanks a lot, it was as expected :-( but the error _is_ around there, it's uninitialized fb_ptr i guess, just searching how to initialize it. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Stan Swiercz (swiercz) Date: 2005-03-24 15:44 Message: Logged In: YES user_id=2345 I have applied the patch and found no difference. Stan ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-24 15:29 Message: Logged In: YES user_id=929 maybe the infamous "Solaris compiler bug" is just an uninitialized variable t1_save_offset? It's unclear, as it seems that this could happen only if the font is not being included. Anyway: Could some Solaris freak try out the attached tiny patch to writet1.c? Regards, Hartmut ---------------------------------------------------------------------- Comment By: Thomas Esser (tetex) Date: 2005-03-24 01:35 Message: Logged In: YES user_id=1230 We have seen this before. pdftex list, posting by Adrian Lanz, Mon, 09 Aug 2004. There was no real outcome of that thread. Adrian wrote on 23 Sep 2004 to the texlive list: > On Tue, Sep 21, 2004 at 07:18:23PM -0500, Maksym Polyakov wrote: >> apparently there was some overflow in /Length1 -- it should be 810 > > Ah, now it sounds familiar. Adrian Lanz has reported the same to > pdftex(a)tug.org (09 Aug 2004, he uses SUN Solaris 9 / gcc 3.3.2). > Yes, I had exactly the same problem recently installing teTeX-beta 2.96.7.20040721. In my case, the symptom was that pdflatex run without error, but a wrong /Length1 parameter was inserted in the PDF output file, which evidently caused Acrobat Reader's error message (no problem, however, with xpdf or with the "dvips -Ppdf" routine). I think I solved the problem by changing the order and rules how shared libraries are found and handled on my Sun Sparc Solaris 2.9 system, and/or I may have re-installed some programs and libraries (ncurses, gettext, libiconv). I am sorry not being more specific on So, we have at least three people with this problem: Stan Swiercz, Maksym Polyakov, Adrian Lanz. I think that this is some king of compiler bug or something like that... Thomas ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-03-23 15:42 Message: Logged In: YES user_id=421 Yes, this is definitely a problem for some specific solaris installations which I can't reproduce. ---------------------------------------------------------------------- Comment By: Stan Swiercz (swiercz) Date: 2005-03-23 15:08 Message: Logged In: YES user_id=2345 I have done more debugging and I find that with a newer solaris 9 kernel the executable works fine. There is some patch to the OS that fixes this. This is something static as when I run this executable on a solaris machine running an older solaris9 kernel or solaris8 it works properly. Further digging I find that when I run the linker command on the older solaris 9 machine it produces a faulty executable BUT if I run "g++ -v" to see what the real linking command is and cut and paste it so as to run it instead the executable produces a pdf viewable with acroread. The basic g++ link command is c++ -o pdfetex pdfetexini.o pdfetex0.o pdfetex1.o pdfetex2.o pdfetex3.o pdfetexextra.o ../../libs/md5/md5.o pdftexdir/libpdf.a ../../libs/libpng/libpng.a ../../libs/zlib/libz.a ../../libs/xpdf/xpdf/libxpdf.a ../../libs/xpdf/goo/libGoo.a ../../libs/xpdf/fofi/libfofi.a -lsocket lib/lib.a ../kpathsea/.libs/libkpathsea.a -lm Instead of running this on older kernels I used /encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/collect2 -V -Y P,/usr/ccs/lib:/usr/lib -L /local/lib -L /encs/lib -Qy -o pdfetex /encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/crt1.o /encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/crti.o /usr/ccs/lib/values-Xa.o /encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/crtbegin.o -L/encs/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3.2 -L/encs/bin/../lib/gcc-lib -L/encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2 -L/usr/ccs/bin -L/usr/ccs/lib -L/encs/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../.. -L/encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../.. pdfetexini.o pdfetex0.o pdfetex1.o pdfetex2.o pdfetex3.o pdfetexextra.o ../../libs/md5/md5.o pdftexdir/libpdf.a ../../libs/libpng/libpng.a ../../libs/zlib/libz.a ../../libs/xpdf/xpdf/libxpdf.a ../../libs/xpdf/goo/libGoo.a ../../libs/xpdf/fofi/libfofi.a -lsocket lib/lib.a ../kpathsea/.libs/libkpathsea.a -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc -lc /encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/crtend.o /encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/crtn.o For the record /usr/ccs/lib/values-Xa.o is the same on both systems. I don't understrand... I also tracked down what the difference was between a pdf file that displays and does not display. The one that does display correctly has /Type /Page /Contents 49 0 R /Resources 47 0 R /MediaBox [0 0 612 792] /Parent 25 0 R >> endobj 47 0 obj <> /ProcSet [ /PDF /Text ] >> endobj 45 0 obj << /Length1 946 /Length2 3204 /Length3 532 /Length 3847 /Filter /FlateDecode while the one that does not has /Type /Page /Contents 49 0 R /Resources 47 0 R /MediaBox [0 0 612 792] /Parent 25 0 R >> endobj 47 0 obj <> /ProcSet [ /PDF /Text ] >> endobj 45 0 obj << /Length1 268436401 /Length2 3204 /Length3 532 /Length 3848 /Filter /FlateDecode the 946 has turned into 268436401! Hope this info helps. Stan ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-03-23 14:25 Message: Logged In: YES user_id=421 This seems to be a build problem on Solaris. Compiling the example on teTeX 3.0 on Linux produces a pdf that shows no problems in AR. A possible cause for the message by AR might be this extract from pdf_test_solaris.pdf: --------- 29 0 obj << /Length1 268436401 /Length2 3204 --------- Length1 is definitely wrong. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-03-23 14:16 Message: Logged In: YES user_id=421 I can reproduce the problem with AR5 and AR7(latest "beta") on Linux. I can't reproduce it with gs 8.50 and Jaws. I suspect that this is a bug in AR. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=315&group_id=106

1 0

[ pdftex-Bugs-315 ] pdflatex on solaris font problems with acroread
by noreply＠sarovar.org 24 Mar '05

24 Mar '05

Bugs item #315, was opened at 2005-03-21 16:53 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=315&group_id=106 Category: Fonts Group: v1.21a >Status: Open Resolution: Fixed Priority: 5 Submitted By: Stan Swiercz (swiercz) Assigned to: Martin Schröder (oneiros) Summary: pdflatex on solaris font problems with acroread Initial Comment: I have compiled pdflatex 1.2.1a that comes with teTeX 3.0 on both linux and solaris. The linux version works properly but the solaris one does not. The last font included in the pdf output produces the error: Unable to extract the embedded font 'KTGBVU+CMR8'. Some characters may not display or print correctly. when viewed with acroread (version 5 or 6, windows, linux and solaris versions). Note that no error is seen when viewed with ghostscript and xpdf. The above error comes from the file: ------------------------ \documentclass{article} \newcommand{\ip}[2]{(#1, #2)} \begin{document} This is an example input file. Footnotes \footnote{This is an example of a footnote.} pose no problem. \LaTeX\ is good at typesetting mathematical formulas like $ x-3y + z = 7 $ or $ a_{1} > x^{2n} + y^{2n} > x' $ or $ \ip{A}{B} = \sum_{i} a_{i} b_{i} $. The spaces you type in a formula are ignored. Remember that a letter like $x$ % $ ... $ and $ ... $ are equivalent is a formula when it denotes a mathematical symbol, and it should be typed as one. \end{document} ----------------------- The sigma is produced correctly. If however I comment out the footnote, the sigma in the summation is no longer viewable and the error message is Unable to extract the embedded font 'ATSTIO+CMEX10'. Some characters may not display or print correctly. I attach a pdf files produced on solaris. Is this a know problem with a patch available? If you need further information please do not hesitate to contact me. Stan ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-24 16:48 Message: Logged In: YES user_id=929 who is pulling this bug into the "closed area"? :-) It seems to work but it still looks weird, maybe the final patch will be different... Regards, Hartmut ---------------------------------------------------------------------- Comment By: Stan Swiercz (swiercz) Date: 2005-03-24 16:18 Message: Logged In: YES user_id=2345 The ptexmac.h patch fixed it. Thank you! Stan ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-24 16:04 Message: Logged In: YES user_id=929 once again, please try the patch for ptexmac.h. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Stan Swiercz (swiercz) Date: 2005-03-24 16:01 Message: Logged In: YES user_id=2345 It does appear that t1_offset_value is at fault. I put in a pdftex_warn (something easy to add) in writet1.c and the first time it outputs I see Warning: pdflatex (file /nfs/encs/ArchDep/sun4.solaris8/pkg/teTeX-3.0/root/texm f/fonts/type1/bluesky/cm/cmr8.pfb): -268435455 t1_save_offset value All the other times the "warning" is displayed it returns 0. Stan ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-24 15:52 Message: Logged In: YES user_id=929 thanks a lot, it was as expected :-( but the error _is_ around there, it's uninitialized fb_ptr i guess, just searching how to initialize it. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Stan Swiercz (swiercz) Date: 2005-03-24 15:44 Message: Logged In: YES user_id=2345 I have applied the patch and found no difference. Stan ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-03-24 15:29 Message: Logged In: YES user_id=929 maybe the infamous "Solaris compiler bug" is just an uninitialized variable t1_save_offset? It's unclear, as it seems that this could happen only if the font is not being included. Anyway: Could some Solaris freak try out the attached tiny patch to writet1.c? Regards, Hartmut ---------------------------------------------------------------------- Comment By: Thomas Esser (tetex) Date: 2005-03-24 01:35 Message: Logged In: YES user_id=1230 We have seen this before. pdftex list, posting by Adrian Lanz, Mon, 09 Aug 2004. There was no real outcome of that thread. Adrian wrote on 23 Sep 2004 to the texlive list: > On Tue, Sep 21, 2004 at 07:18:23PM -0500, Maksym Polyakov wrote: >> apparently there was some overflow in /Length1 -- it should be 810 > > Ah, now it sounds familiar. Adrian Lanz has reported the same to > pdftex(a)tug.org (09 Aug 2004, he uses SUN Solaris 9 / gcc 3.3.2). > Yes, I had exactly the same problem recently installing teTeX-beta 2.96.7.20040721. In my case, the symptom was that pdflatex run without error, but a wrong /Length1 parameter was inserted in the PDF output file, which evidently caused Acrobat Reader's error message (no problem, however, with xpdf or with the "dvips -Ppdf" routine). I think I solved the problem by changing the order and rules how shared libraries are found and handled on my Sun Sparc Solaris 2.9 system, and/or I may have re-installed some programs and libraries (ncurses, gettext, libiconv). I am sorry not being more specific on So, we have at least three people with this problem: Stan Swiercz, Maksym Polyakov, Adrian Lanz. I think that this is some king of compiler bug or something like that... Thomas ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-03-23 15:42 Message: Logged In: YES user_id=421 Yes, this is definitely a problem for some specific solaris installations which I can't reproduce. ---------------------------------------------------------------------- Comment By: Stan Swiercz (swiercz) Date: 2005-03-23 15:08 Message: Logged In: YES user_id=2345 I have done more debugging and I find that with a newer solaris 9 kernel the executable works fine. There is some patch to the OS that fixes this. This is something static as when I run this executable on a solaris machine running an older solaris9 kernel or solaris8 it works properly. Further digging I find that when I run the linker command on the older solaris 9 machine it produces a faulty executable BUT if I run "g++ -v" to see what the real linking command is and cut and paste it so as to run it instead the executable produces a pdf viewable with acroread. The basic g++ link command is c++ -o pdfetex pdfetexini.o pdfetex0.o pdfetex1.o pdfetex2.o pdfetex3.o pdfetexextra.o ../../libs/md5/md5.o pdftexdir/libpdf.a ../../libs/libpng/libpng.a ../../libs/zlib/libz.a ../../libs/xpdf/xpdf/libxpdf.a ../../libs/xpdf/goo/libGoo.a ../../libs/xpdf/fofi/libfofi.a -lsocket lib/lib.a ../kpathsea/.libs/libkpathsea.a -lm Instead of running this on older kernels I used /encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/collect2 -V -Y P,/usr/ccs/lib:/usr/lib -L /local/lib -L /encs/lib -Qy -o pdfetex /encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/crt1.o /encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/crti.o /usr/ccs/lib/values-Xa.o /encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/crtbegin.o -L/encs/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3.2 -L/encs/bin/../lib/gcc-lib -L/encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2 -L/usr/ccs/bin -L/usr/ccs/lib -L/encs/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../.. -L/encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/../../.. pdfetexini.o pdfetex0.o pdfetex1.o pdfetex2.o pdfetex3.o pdfetexextra.o ../../libs/md5/md5.o pdftexdir/libpdf.a ../../libs/libpng/libpng.a ../../libs/zlib/libz.a ../../libs/xpdf/xpdf/libxpdf.a ../../libs/xpdf/goo/libGoo.a ../../libs/xpdf/fofi/libfofi.a -lsocket lib/lib.a ../kpathsea/.libs/libkpathsea.a -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc -lc /encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/crtend.o /encs/pkg/gcc-3.3.2/root/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/crtn.o For the record /usr/ccs/lib/values-Xa.o is the same on both systems. I don't understrand... I also tracked down what the difference was between a pdf file that displays and does not display. The one that does display correctly has /Type /Page /Contents 49 0 R /Resources 47 0 R /MediaBox [0 0 612 792] /Parent 25 0 R >> endobj 47 0 obj <> /ProcSet [ /PDF /Text ] >> endobj 45 0 obj << /Length1 946 /Length2 3204 /Length3 532 /Length 3847 /Filter /FlateDecode while the one that does not has /Type /Page /Contents 49 0 R /Resources 47 0 R /MediaBox [0 0 612 792] /Parent 25 0 R >> endobj 47 0 obj <> /ProcSet [ /PDF /Text ] >> endobj 45 0 obj << /Length1 268436401 /Length2 3204 /Length3 532 /Length 3848 /Filter /FlateDecode the 946 has turned into 268436401! Hope this info helps. Stan ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-03-23 14:25 Message: Logged In: YES user_id=421 This seems to be a build problem on Solaris. Compiling the example on teTeX 3.0 on Linux produces a pdf that shows no problems in AR. A possible cause for the message by AR might be this extract from pdf_test_solaris.pdf: --------- 29 0 obj << /Length1 268436401 /Length2 3204 --------- Length1 is definitely wrong. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-03-23 14:16 Message: Logged In: YES user_id=421 I can reproduce the problem with AR5 and AR7(latest "beta") on Linux. I can't reproduce it with gs 8.50 and Jaws. I suspect that this is a bug in AR. :-( ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=315&group_id=106

1 0