September 2010 - ntg-pdftex - NTG Mailing Lists

[pdftex-Bugs][4315] pdftex manual is not up-to-date
by pdftex-bugs＠sarovar.org 17 Sep '10

17 Sep '10

Bugs item #4315, was opened at 2010-07-30 06:49 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: The Thanh Han (hanthethanh) Summary: pdftex manual is not up-to-date Category: Documentation Group: None Resolution: Accepted Initial Comment: The manual needs some correction: \pdfelapsedtime: poor wording \letterspacefont: missing \pdfinclusioncopyfonts: missing ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2010-09-17 07:05 Message: \pdfstrcmp: missing ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4315&group_id=106

1 0

[pdftex-Patches][2087] Support for CMap namespaces
by pdftex-patches＠sarovar.org 08 Sep '10

08 Sep '10

Patches item #2087, was opened at 2008-08-28 08:17 >Status: Open Priority: 3 Submitted By: Vasile Gaburici (vga) >Assigned to: The Thanh Han (hanthethanh) Summary: Support for CMap namespaces Category: Fonts Group: v1.40.0 Resolution: Accepted Initial Comment: There are a couple of LaTeX packages out there (cmap and mmap) that provide CMaps. They don't work as well as \pdfglyphtounicode, i.e. virtual fonts don't get CMaps at all (the CMap is included in the PDF but not referenced), and otftotfm-installed fonts lack the CMap entries for the ligatures that otftotfm sneaks in empty slots. As you know, \pdfglyphtounicode fixes these problems. On the other hand, these two packages let the user specify a CMap for each LaTeX encoding, so the user ca give different Unicode values to the same PS glyph name in different LaTeX encodings. Of course that works properly only if the fonts invoked by the different LaTeX encodings are different; otherwise only one can win the \pdffontattr. A compelling application of this feature are CMaps that set math code points (usually above BMP) for TeX math fonts; those glyphs have exactly the same names as in text fonts /A etc. Adding namespaces to \pdfglyphtounicode makes those two packages obsolete in their current implementation. Another advantage of namespaces is the ability to (reliably) fix TrueType font CMaps. The troublesome glyphs are usually ligatures that don't have a Unicode entry (Th, ti, tf, ffb, etc.), which otftotfm writes as /indexZZZ in the enc file. Putting those in a per-font namespace avoids any potential clashes. So, I've patched pdftex to provide namespaces using the following syntax extension: the first argument of \pdfglyphtounicode can now take additional forms: \pdfglyphtounicode{fnt:tex-font-name/ps-glyph-name}{...} \pdfglyphtounicode{enc:ps-enc-name/ps-glyph-name}{...} Since fonts for which the built-in encoding is used happen to be exactly those that have multiple design sizes (cmr, stmary etc.), using a separate ps-enc-name for each is not helpful. Instead, the 'enc' namespace for those is obtained by dropping any final digits from the font name, e.g. cmr10 has PS encoding cmr (for CMap purposes only). The search policy is to first search the font namespce, then the encoding, and finally the global namespace, for which the syntax remains unchanged. All these namespace are implemented in the same avl tree; just using the above strings as key names. In theory this makes the search 3 times slower, but that particular phase of pdftex hardly takes any time, so it seemed premature to implement any optimization. Some usage examples: % make the ti ligature searchable in Calibri regular \pdfglyphtounicode{fnt:calibly1--base/index415}{0074 0069} % go crazy with Unicode math; TeX math italic gives above-BMP math A \pdfglyphtounicode{enc:cmmi/A}{D835 DC34} % UTF16BE required Note that search behavior for math letters varies with pdf viewers. Acrobat implements only canonical equivalence, so you need to enter the exact code point, and copy/paste preserves the code points, so you can paste into a LaTeX document if it's using utf8x input encoding. Evince implements compatibility equivalence, so it's easier to find those math As by searching for plain A, but they also copy/paste as plain A. You can use pdftotext however, which uses the same poppler backend, to have the code points are preserved. I'm not really advocating Unicode math letters, but now they're easily supported in pdftex -- no need for manual CMaps anymore. BTW, \pdfglyphtounicode now really needs to be documented in the manual, so people would stop writing (buggy) CMaps by hand. I volunteer to do it if you accept the patch :) ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2010-09-08 08:36 Message: re-open this case, since the "enc" namespace seems useful and would make glyphtounicode.tex simpler. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-12-01 22:02 Message: included in 1.40.10 ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-07 14:59 Message: this patch is indeed very useful, however adding tfm namespace support is enough since it can cover the other case. I have changed the patch slightly to: - drop the enc: case - use "tfm:" instead of "fnt:" as the tfm namespace prefix And added a small test file. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=2087&group_id=106

1 0

[pdftex-Bugs][896] including an image (pdf or png) with transparency messes up other colours on that page
by pdftex-bugs＠sarovar.org 04 Sep '10

04 Sep '10

Bugs item #896, was opened at 2007-12-29 21:00 Status: Closed Priority: 3 Submitted By: Jim Diamond (zsd) Assigned to: Martin Schröder (oneiros) Summary: including an image (pdf or png) with transparency messes up other colours on that page Category: Image inclusion Group: v1.50.0-alpha Resolution: Fixed Initial Comment: Download http://www.libpng.org/pub/png/img_png/stefan_255_rgba.png (which has a transparent background) and run it through png2pdf as follows: png2pdf -i stefan_255_rgba.png stefan_255_rgba-i.pdf png2pdf -a stefan_255_rgba.png stefan_255_rgba-a.pdf png2pdf stefan_255_rgba.png stefan_255_rgba-neither.pdf Then run the following through pdflatex (pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)) \documentclass{beamer} \mode<presentation> { \usetheme{Madrid} \setbeamercovered{transparent} } \usepackage{ifpdf} \usepackage{graphicx} \usepackage{color} \ifpdf \hypersetup{% pdfpagemode=FullScreen, pdfpagetransition={Wipe /Di 0 /D 0.5} } \fi \title[Beamer and png2pdf]{Using png2pdf with the beamer class} \author[Krause]{D.~Krause} \subject{png2pdf} \begin{document} \beamertemplateshadingbackground{yellow!50}{magenta!50} \begin{frame} \frametitle{NO Image over background} This is some text \end{frame} \begin{frame} \frametitle{Original stefan... png image over background} \includegraphics{stefan_255_rgba.png}% \end{frame} \begin{frame} \frametitle{png2pdf -a stefan... image over background} \includegraphics{stefan_255_rgba-a.pdf}% \end{frame} \begin{frame} \frametitle{png2pdf -i stefan... image over background} \includegraphics{stefan_255_rgba-i.pdf}% \end{frame} \begin{frame} \frametitle{png2pdf stefan... over background} \includegraphics{stefan_255_rgba-neither.pdf}% \end{frame} \end{document} Now look at the resulting PDF (attached) with Acroread 7.0.9 or 8.1.1 on Linux. On the page which includes the PNG and also on the page which includes the png2pdf -a version, the other colours on the page are messed up somewhat. This also happens on Acroread 8.? running on Windoze xp under vmware, although it seems a bit less noticeable. There is no apparent problem when looking at the file with xpdf or kpdf (Slackware 12.0 Linux). It's not clear to me whether this is an acroread bug or a pdftex bug, but Martin Schröder suggested I open a bug here. Cheers. Jim ---------------------------------------------------------------------- Comment By: Yannick B (bers) Date: 2010-09-04 09:38 Message: Hi, I just ran this example through pdfTex 1.40.11 (MiKTeX 2.9 beta). What I found out is that this issue is fixed for the png, but not for the transparent pdf file (png2pdf -a). File: beamer_1.40.11.pdf. You see that the colors on slides 1 and 2 are different. This might need another fix. (I assume it worked once, but was accidently removed in a later revision, perhaps due to what I'll point out now.) I also noted that the bug fix for the png has a very ugly side-effect, which I illustrate by two snapshots (snapshot_original.png, snapshot_1.40.11.png). You clearly see that the white font is more "bold" in the new version; also, you note a white frame around the image, and that the symbols in the lower right corner show some artifacts - especially the circle-arrows. This is a rendering issue in Acrobat on some systems, which has been encountered and described by others already. A minimal example of this effect can for example be found here: http://forums.adobe.com/message/3108003 A reason for this might be the missing inclusion of "blending space" information, as pointed out in the reply to above's post. This same issue has also been described for pdf file inclusion, see here: http://sarovar.org/tracker/?func=detail&atid=493&aid=4294&group_id=106 In that case, it is based on incomplete page group information of the included pdf. However, as also pointed out in that discussion, a new page group is synthesized for png files, so there needs to be something wrong with that. It is really an annoying bug, as pages with an without transparent pngs in them may look different to your reader. I do not have enough knowledge to assign the different effects to their respective root causes, but I do believe that this bug entry here might be a good starting point. Last question: How do I attach files? I will as soon as I have found out. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-01-14 17:25 Message: Logged In: YES user_id=421 A fix for this will be included in the next release (1.40.6/1.50.0). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-31 16:07 Message: Logged In: YES user_id=421 Our contact at adobe confirms that pages with transparent objects on them (like pngs) must have a /Group entry in the /Page object. I'll fix that next year. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-29 22:05 Message: Logged In: YES user_id=421 This is not related to #764, as there are no page Groups. It also happens only with the png or rgba-a. I'll ask our contact at Adobe. ---------------------------------------------------------------------- Comment By: Jim Diamond (zsd) Date: 2007-12-29 22:03 Message: Logged In: YES user_id=4814 I just d/l'ed and compiled pdftex Version 3.141592-1.40.5 (Web2C 7.5.6) The pdf files (1.40.3 and 1.40.5 versions) are slightly different (when compared as text) but when viewed with acroread 7.0.9 they look identical (as far as my eyes can tell). ---------------------------------------------------------------------- Comment By: Jim Diamond (zsd) Date: 2007-12-29 21:15 Message: Logged In: YES user_id=4814 Done ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-12-29 21:08 Message: Logged In: YES user_id=421 Please attach the pdfs from png2pdf. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=896&group_id=106

1 0