- ntg-pdftex - NTG Mailing Lists

pdfcurpageref -- does it make sense?
by The Thanh Han 28 Jan '05

28 Jan '05

Hi, I wonder how Hans and other would solve this problem. tex doesn't have a concept of `current page' while processing the input token list. The page number can be detected reliably only using 2nd pass processing, as the page where some material ends up is known only at shipping phase. It is possible to provide a primitive which returns the *next* page object number, but IMHO it doesn't make any sense. Thanh > Feature Requests item #252, was opened at 2004-12-14 16:47 > You can respond by visiting: > http://sarovar.org/tracker/?func=detail&atid=496&aid=252&group_id=106 > > Category: None > Group: None > Status: Open > Resolution: None > Priority: 5 > Submitted By: Nobody (None) > Assigned to: Nobody (None) > Summary: current page object number > > Initial Comment: > Dear PdfTeX-developpers, > > sometimes the reference to the current page object is > needed within the implementation of another pdf object. > > As an example may serve the `Screen Annotation' > several interactive PDF features rely on. > > Currently, the \pdfpageref command, which takes a page > number as argument, can be used for this purpose. > > It is difficult, however, to maintain a reliable page > counter as the attached file demonstrates. It uses the > `everyshi' package by M. Schroeder. > > On the first line of every page a wrong object number > is being output. > > It would be very nice to have a command like > \pdfcurrentpageref to be implemented in pdftex. > > Thanks for your attention, > > Alexander Grahn

2 2

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

27 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: 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-242 ] Assertion failure when including pdf file without embedded fonts
by noreply＠sarovar.org 27 Jan '05

27 Jan '05

Bugs item #242, was opened at 2004-12-02 15:31 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=242&group_id=106 Category: Fonts Group: v1.20b >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody (None) Assigned to: Hartmut Henkel (hhenkel) Summary: Assertion failure when including pdf file without embedded fonts Initial Comment: See included shell script ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2005-01-21 00:38 Message: Logged In: NO I’ve already contacted the owner of LJBOOK.com and he doesn’t see a problem with it on his end. I don’t know if it has something to do with the PDF or not. I’m writing in English in the United States. I have Adobe Reader 6.0. I’ve tried multiple times to make a copy of my Livejournal through ljbook.com without success. I have a lot of entries, all “friends only” or “private” from 2002 to 2005. When I make the copy of my journal into the PDF, a majority of the words with apostrophes and “quotes” like I’ll, Don’t, She’s, Couldn’t, That’s, How’s, etc. gets replaced by a symbol that looks like a weird letter “a” with something on top of it. The actual apostrophe gets replaced with the symbol and makes those words look separated and weird. I’ve tried multiple times and the same problem occurs. It shows more in the years 2004 and 2005 but it does show in the 2002 and 2003 entries also, when it’s in the PDF. I also tried those years on its own and get the same problem. I have the “Auto-convert older entries from” set correctly and the encodings set properly and still have the problem. Could you please help me out? I’m really in need to backup my journal and don’t know why almost all the words that have apostrophes are turning the apostrophes into that symbol when it’s in the PDF format. When it’s in my regular Livejournal, it’s perfect and doesn’t show that. Just when it’s backed up into the PDF. Please help me out. I would really appreciate it a lot. Thank you very much in advance. liveatshea(a)hotmail.com ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-01-13 00:19 Message: Logged In: YES user_id=929 This is a patch for file mapfile.c of pdftex-1.20, cleaning up a few bugs introduced by patch-242c. The obsolete qualifier "!" is removed from scanning. Blank handling between qualifiers "<", "<<" and .enc and f_name names has been re-introduced, to make it backward compatible and compatible to the preferences of map file writers. Please test carefully. Help welcome. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-12-22 15:53 Message: Logged In: YES user_id=421 This has been fixed in 1.20b ---------------------------------------------------------------------- Comment By: Thomas Esser (tetex) Date: 2004-12-03 00:30 Message: Logged In: YES user_id=1230 I can reproduce this bug after updmap --setoption pdftexDownloadBase14 false Thomas ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=242&group_id=106

1 0

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

27 Jan '05

Bugs item #262, was opened at 2005-01-21 09:44 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=262&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody (None) Assigned to: Nobody (None) 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: The Thanh Han (hanthethanh) Date: 2005-01-27 09: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 13: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 22: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 14: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 09: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

Fwd: xpdf library bug? (fwd)
by Hartmut Henkel 26 Jan '05

26 Jan '05

---------- Forwarded message ---------- Date: Wed, 26 Jan 2005 16:19:22 -0500 From: Martin Otte <otte(a)duke.edu> To: Hartmut Henkel <hartmut_henkel(a)gmx.de> Cc: karl(a)freefriends.org, Gerben Wierda <Gerben.Wierda(a)rna.nl> Subject: Fwd: xpdf library bug? Hi, I noticed in the latest pdftex-1.20c-beta-20050121 is a patch that I made to the file FoFiType1.cc which corrects a seg-fault in pdftex that occurs when including a document with the Mathematica fonts. It is probably preferable to instead use the patch from the pdf maintainer, which should be included with this email. If you have already made this change, then please disregard my email. Thanks, Martin Otte Begin forwarded message: > From: "Derek B. Noonburg" <derekn(a)foolabs.com> > Date: January 19, 2005 12:39:17 AM EST > To: karl(a)freefriends.org > Cc: Gerben.Wierda(a)rna.nl, frank(a)wizards.de, andrew(a)stone.com, > otte(a)duke.edu > Subject: Re: xpdf library bug? > Reply-To: "Derek B. Noonburg" <derekn(a)foolabs.com> > > On 12 Jan, Karl Berry wrote: >> Greetings, >> >> The tex-live list got this bug report regarding the xpdf library. >> You can get the attachments from >> http://tug.org/pipermail/tex-live/2005-January/007617.html >> >> Thanks, >> karl >> >> Subject: pdflatex segmentation fault and patch to fix >> From: "Martin Otte" <otte(a)duke.edu> >> Date: Tue, January 11, 2005 23:40 >> To: gerben.wierda(a)rna.nl >> >> Hi, >> >> Thanks for your excellent packaging of tex/latex for the mac. >> >> I am using the TeX Live 2004 and teTeX 3 distribution from the tex >> i-package released on 2004/12/01. >> >> With this i-package, pdflatex always seg-faults for me when I include >> pdf >> figures generated using the PStill postscript-to-pdf converter. These >> pdfs open fine with Acrobat and Preview. I downloaded the final TeX >> Live >> 2004 source package, compiled pdfetex, ran the executable under a >> debugger and found that pdflatex crashes in the xpdf library. I then >> verified that these pdf's also crash the xpdf viewer on my linux >> machine. >> >> The crash occurs in the file libs/xpdf/fofi/FoFiType1.cc. There is a >> string buffer size variable "n" that becomes negative and causes the >> program to crash. I attached a patch that can be used from the libs >> directory of the TeX Live distribution that prevents the buffer size >> from >> becoming negative. > > That's a known bug in Xpdf 3.00. I'm attaching a patch file which > should fix it. > > - Derek

1 0

pdf inclusion
by Hans Hagen 26 Jan '05

26 Jan '05

Hi, I was wondering, it it technically difficult to include a specific xobject (xform) from a pdf file (not so much different from including a page) 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 1

Re: [tex-k] Dvips fix for font in EPSF improperly downloaded
by Tomas G. Rokicki 24 Jan '05

24 Jan '05

All your points are good, but I clain the "fix" is still an improvement, and for that reason I am leaving it in there. Perhaps I am naive, but if someone gives me an environment in which there are multiple, and distinctly different, fonts, with the same /FontName, I claim all bets are off. I have encountered this before and it's not a good situation. At this time I simply don't have a solution for a case like this. On the other hand, I do agree that it is better to rename the TeX fonts if we will partially subset them. I believe we should do this (assuming technically we can make it work; I do not know that we cannot, nor do I know of specific issues, but I would not be surprised if this breaks something). Of course there are legal issues with renaming a font too, most likely. :-) This is something to consider for the next release (not only of dvips but also of pdftex, I believe). But I believe this is a substantial change to a piece of code that I am simply not familiar enough with to mess with. I do know that I have had in the past substantial problems with just changing the UniqueID of the font; different interpreters were very unhappy with some of the changes I made and I had to back them out. But that's just a technical issue. On the legal issue: I agree a warning may be appropriate whenever a font is included in its entirety. Right now dvips turns a deaf ear to these issues, but it is perhaps time for it to support at the very least a warning message. Another alternative is to run all included graphics through a companion interpreter that's been configured to only collect information on what characters and what fonts are used (probably by redefining show and a few other operators). But this is another substantial undertaking. Just so we are very clear: is it your position that this change that was made should be reversed? Or improved before the next release? Both of these positions would be troublesome for me. If it's just a question of, here's some additional issues to consider and let's try to get a solution to them as quickly as possible, I could not agree more. I must say that I've had no indication that the problems you mention are severe (i.e., causing problems for people), but perhaps that is because I don't follow most of the TeX groups. I believe this is a discussion that we should have as part of a larger group, so I am happy to have gotten your note, and I hope our collected wisdom on these groups will steer us all in the appropriate direction. But for now I've got to get a point release out the door. -tom

6 6

Re: [tex-k] Dvips fix for font in EPSF improperly downloaded
by Reinhard Kotucha 23 Jan '05

23 Jan '05

I send a copy to ntg-pdftex(a)ntg.nl because I don't know how pdftex deals with fonts in embedded PDF files. >>>>> "Tomas" == Tomas G Rokicki <rokicki(a)CS.Stanford.EDU> writes: > I just submitted a fix for the problem where a document includes a > figure that uses a downloaded PostScript font, and that same font > is also used by the main document itself. Dvips was partially > downloading the font in this case when it should have downloaded > the entire font. It now does download the entire font. If I understand you correctly, you want to put the entire font into the output file if the /FontName of the font in the included eps-file is the same as a font used by TeX (the /FontName in psfonts.map). This will solve a few problems but not all. The main problem is that this solution assumes that a font in an embedded eps file and a font in texmf with the same /FontName are identical. But unfortunately we cannot rely on this. One example is /Courier. http://ms25.ath.cx/courier.pdf shows the difference between /leftquote in URW Courier and IBM Courier provided by XFree86 (/usr/X11R6/lib/fonts/Type1/cour.pfa). If you have problems downloading the file, let me know. Both have "/FontName /Courier def" but they are totally different. Another problem are the free URW fonts. They are under GPL and someone added cyrillic glyphs to the fonts. The modified fonts are distributed with ghostscript. When I looked into them, they still needed some refinement. Walter Schmidt maintains the original URW fonts on CTAN for exactly this reason. Assume that someone creates an eps file using the cyrillic glyphs from the gs fonts, does it really help if dvips include the entire font from the the texmf tree (which does not have cyrillic glyphs)? I think it's better not to touch eps files if possible. People expect that if they can be printed, they can be included into a TeX document. In most cases you get better results if you replace an embedded font by one provided by a TeX distribution but in some cases the result might be not what people expect. Checking the /UniqueID would minimize the risk but for fonts under GPL I wouldn't even rely on this. Isn't it better to rename the TeX fonts (the fonts mentioned in dvips.map)? For instance, from psfonts.map: bchb8r CharterBT-Bold "TeXBase1Encoding ReEncodeFont" <8r.enc <bchb8a.pfb When loading a font, replace "/CharterBT-Bold" by "/bchb8a" and then "/bchb8a findfont" instead of "/CharterBT-Bold findfont". There are some legal problems as well. If the user requires subsetting in psfonts.map and for some reason the entire font is included, there should at least be a warning message on screen. Some font suppliers disallow distribution of files containing entire fonts. Your approach leads to smaller files. I like this, of course. Maybe checking the /UniqueID is sufficient if we assume that people providing modified fonts are clever enough to change the /UniqueID as well. I must admit that I don't know whether you already do this. At the DANTE-2003 I had a discussion about problems like this with Walter Schmidt. At this time he was thinking about changing /FontName in the free URW fonts on CTAN, but I disliked this approach because it only solves problems with the fonts he maintains. Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------

1 0

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

22 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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody (None) Assigned to: Nobody (None) 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: 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-262 ] Type42 inclusion
by noreply＠sarovar.org 21 Jan '05

21 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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody (None) Assigned to: Nobody (None) 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-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-262 ] Type42 inclusion
by noreply＠sarovar.org 21 Jan '05

21 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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody (None) Assigned to: Nobody (None) 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: 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-262 ] Type42 inclusion
by noreply＠sarovar.org 21 Jan '05

21 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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody (None) Assigned to: Nobody (None) 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-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

2 1

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

21 Jan '05

Bugs item #262, was opened at 2005-01-21 15:14 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=262&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody (None) Assigned to: Nobody (None) 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 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=262&group_id=106

1 0

[ pdftex-Bugs-242 ] Assertion failure when including pdf file without embedded fonts
by noreply＠sarovar.org 21 Jan '05

21 Jan '05

Bugs item #242, was opened at 2004-12-02 20:01 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=242&group_id=106 Category: Fonts Group: v1.20b Status: Open Resolution: Fixed Priority: 5 Submitted By: Nobody (None) Assigned to: Hartmut Henkel (hhenkel) Summary: Assertion failure when including pdf file without embedded fonts Initial Comment: See included shell script ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2005-01-21 05:08 Message: Logged In: NO I’ve already contacted the owner of LJBOOK.com and he doesn’t see a problem with it on his end. I don’t know if it has something to do with the PDF or not. I’m writing in English in the United States. I have Adobe Reader 6.0. I’ve tried multiple times to make a copy of my Livejournal through ljbook.com without success. I have a lot of entries, all “friends only” or “private” from 2002 to 2005. When I make the copy of my journal into the PDF, a majority of the words with apostrophes and “quotes” like I’ll, Don’t, She’s, Couldn’t, That’s, How’s, etc. gets replaced by a symbol that looks like a weird letter “a” with something on top of it. The actual apostrophe gets replaced with the symbol and makes those words look separated and weird. I’ve tried multiple times and the same problem occurs. It shows more in the years 2004 and 2005 but it does show in the 2002 and 2003 entries also, when it’s in the PDF. I also tried those years on its own and get the same problem. I have the “Auto-convert older entries from” set correctly and the encodings set properly and still have the problem. Could you please help me out? I’m really in need to backup my journal and don’t know why almost all the words that have apostrophes are turning the apostrophes into that symbol when it’s in the PDF format. When it’s in my regular Livejournal, it’s perfect and doesn’t show that. Just when it’s backed up into the PDF. Please help me out. I would really appreciate it a lot. Thank you very much in advance. liveatshea(a)hotmail.com ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-01-13 04:49 Message: Logged In: YES user_id=929 This is a patch for file mapfile.c of pdftex-1.20, cleaning up a few bugs introduced by patch-242c. The obsolete qualifier "!" is removed from scanning. Blank handling between qualifiers "<", "<<" and .enc and f_name names has been re-introduced, to make it backward compatible and compatible to the preferences of map file writers. Please test carefully. Help welcome. Regards, Hartmut ---------------------------------------------------------------------- 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: Thomas Esser (tetex) Date: 2004-12-03 05:00 Message: Logged In: YES user_id=1230 I can reproduce this bug after updmap --setoption pdftexDownloadBase14 false Thomas ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=242&group_id=106

1 0

character protrusion with the first letter in a paragraph
by The Thanh Han 19 Jan '05

19 Jan '05

Hi, I have been thinking of the question how to make char protrusion work with the first char of a paragraph. The simplest (and quite robust) solution can be as follows: when considering whether a marginal kern should be inserted, we skip certain kinds of `invisible' node (like adjust node, penalty node and the like). Now to make it work with the first char of a par, we also skip null boxes (box with zero dimen and empty contents) at the left margin. The question is whether such behaviour is ``correct'', and what surprises it can bring in certain situations. Thanh

3 3

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

18 Jan '05

Patches item #257, was opened at 2005-01-10 21:43 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=257&group_id=106 Category: None Group: Unstable (example) Status: Open Resolution: None Priority: 3 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: Experimental patch for pdftex character protrusion Initial Comment: Normally items inside a \hbox are not considered for protrusion. With this experimental patch also nested \hboxes at the left and right margin are recursively searched for items with \lpcode or \rpcode, and the outmost containing boxes are protruded correspondingly. This seems to be practical e. g. if an elevated \footnote{foo} (LaTeX) index happens to be at the right margin; in this case the footnote index normally is placed too far inward the line. This disturbance was detected by Peter Muthesius in an de.comp.text.tex news thread "pdfcprot und Ziffern am rechten Rand" started Sat Jan 08 14:05:23 CET 2005. Rough experimental patch, rudimentarily tested with left and right protrusion, see test file xx.tex with output xx.pdf. Just for discussion. No warranty. Have fun! Regards, Hartmut ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-01-18 22:19 Message: Logged In: YES user_id=929 Character protrusion patch news: * The protrusion character can now be inside deeply nested \hbox{}, with further (also nested) skipable \hbox{} stuff in the way. The nested list will be recursively searched until a non-skipable item (protrusion character, other character, or list end) is found. * Try to solve left protrusion at paragraph start with \parindent=0pt,by selectively skipping over TeX's empty \hbox{} there. * Protrusion character search by 2 new functions find_protchar_left() and find_protchar_right(), and simple stack. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=257&group_id=106

1 0

[Fwd: Re: [NTG-pdftex] Re: [NTG-context] ConTeXt dont work with fonts after last miktex update]
by Hans Hagen 18 Jan '05

18 Jan '05

1 0

Re: [NTG-context] ConTeXt dont work with fonts after last miktex update
by Hartmut Henkel 18 Jan '05

18 Jan '05

On Wed, 12 Jan 2005, Matthias C. Schmidt wrote: > After the last update ConTeXt has problems with fonts unter miktex. > > from the log: > > [1.1{original-empty.map}{texnansiOSFSC-adobe-cronospro.map > Warning: pdfetex (file texnansiOSFSC-adobe-cronospro.map): invalid entry for > `texnansiOSFSC-raw-CronosPro-Bold': invalid font file name > > the entry in the map-file: > > texnansiOSFSC-raw-CronosPro-Bold 4 < CronosPro-Bold.pfb texnansiOSFSC.enc Please remove the blank after the "<": texnansiOSFSC-raw-CronosPro-Bold 4 <CronosPro-Bold.pfb texnansiOSFSC.enc Is it working then? I'm guilty for this change (anywhere else this blank is missing, but it was definitively allowed as i see now -- an undocumented feature). What is the origin of file texnansiOSFSC-adobe-cronospro.map? Is it from somewhere distributed or written by yourself? Regards, Hartmut

6 7

ttf support
by The Thanh Han 17 Jan '05

17 Jan '05

Hi all, I am working on ttf support: 1) will make the subset tag work in the same way as t1; 2) support refering glyphs by their unicode index in map files. In case one has some further ideas for improvements for fixes, please let me know. Regards, Thanh

1 0

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

14 Jan '05

Feature Requests item #254, was opened at 2004-12-22 21: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: None Priority: 5 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: fontexpansion, dvi output Initial Comment: Hello developers, I'd like to use the autoexpand feature with dvips. Are there any plans to make pdftex write the autoexpanded tfm files to the current directory, perhaps even generating a map file? Cheers, Michael ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2005-01-14 02: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

pdfliteral
by Hans Hagen 13 Jan '05

13 Jan '05

Hi, It looks like pdfliteral direct generates an extra newline 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

Re: [NTG-pdftex] where are the pdftex latest sources?
by The Thanh Han 13 Jan '05

13 Jan '05

Thanks to Martin & Hartmut. Regards, Thanh On Wed, Jan 12, 2005 at 05:39:52AM +0100, Hartmut Henkel wrote: > On Tue, 11 Jan 2005, The Thanh Han wrote: > > > are the sources at P4 TL the latest one? > > AFAIK yes, identical to the 1.20b tarball released from sarovar. > > Regards, Hartmut

1 0

[ pdftex-Bugs-242 ] Assertion failure when including pdf file without embedded fonts
by noreply＠sarovar.org 13 Jan '05

13 Jan '05

Bugs item #242, was opened at 2004-12-02 15:31 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=242&group_id=106 Category: Fonts >Group: v1.20b Status: Open Resolution: Fixed Priority: 5 Submitted By: Nobody (None) Assigned to: Hartmut Henkel (hhenkel) Summary: Assertion failure when including pdf file without embedded fonts Initial Comment: See included shell script ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-01-13 00:19 Message: Logged In: YES user_id=929 This is a patch for file mapfile.c of pdftex-1.20, cleaning up a few bugs introduced by patch-242c. The obsolete qualifier "!" is removed from scanning. Blank handling between qualifiers "<", "<<" and .enc and f_name names has been re-introduced, to make it backward compatible and compatible to the preferences of map file writers. Please test carefully. Help welcome. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-12-22 15:53 Message: Logged In: YES user_id=421 This has been fixed in 1.20b ---------------------------------------------------------------------- Comment By: Thomas Esser (tetex) Date: 2004-12-03 00:30 Message: Logged In: YES user_id=1230 I can reproduce this bug after updmap --setoption pdftexDownloadBase14 false Thomas ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=242&group_id=106

1 0

[ pdftex-Bugs-242 ] Assertion failure when including pdf file without embedded fonts
by noreply＠sarovar.org 12 Jan '05

12 Jan '05

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

1 0

where are the pdftex latest sources?
by The Thanh Han 12 Jan '05

12 Jan '05

Hi, are the sources at P4 TL the latest one? Thanh

2 1