January 2005 - ntg-pdftex - NTG Mailing Lists

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

bug?
by Hans Hagen 11 Jan '05

11 Jan '05

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

4 4

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

11 Jan '05

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

3 3

PNG inclusion progress
by Taco Hoekwater 10 Jan '05

10 Jan '05

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

2 1

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

10 Jan '05

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

1 0

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

10 Jan '05

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

2 1

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

07 Jan '05

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

2 1