December 2009 - ntg-pdftex - NTG Mailing Lists

[pdftex-Patches][4299] pdf font inclusion error (with partial patch)
by pdftex-patches＠sarovar.org 24 Dec '09

24 Dec '09

Patches item #4299, was opened at 2009-11-27 10:03 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: pdf font inclusion error (with partial patch) Category: PDF inclusion Group: None Resolution: Accepted Initial Comment: http://www.ntg.nl/pipermail/ntg-pdftex/2009-November/003859.html ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-12-24 10:38 Message: in earlier versions of pdf spec, values in named resources must be indirect object, hence the test isRef(). I looked into the current pdf spec and it seems the above requirement is gone, not sure from which version of pdf. So we can leave out that test now. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=4299&group_id=106

1 0

[pdftex-Patches][4301] Patch to detect/prevent wrong arguments of \pdfsetmatrix
by pdftex-patches＠sarovar.org 23 Dec '09

23 Dec '09

Patches item #4301, was opened at 2009-12-23 15:33 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: Patch to detect/prevent wrong arguments of \pdfsetmatrix Category: Primitives Group: None Resolution: Accepted Initial Comment: from Hartmut: ,--------, please have a look what this file produces: \nopagenumbers \pdfcompresslevel=0 \pdfsetmatrix{1 2 3 4 5 6} \bye ...it's an invalid "cm". I accidentally typed 6 components instead of 4, but i guess that this user error should be caught. `--------` and Heiko's reply: ,--------, I have attached a patch that should fix it: * In case of unrecognized formats the literal isn't output. * The warning is fixed and moved to pdftex.web. `--------` Patch by Heiko is attached. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=4301&group_id=106

1 0

[pdftex-Bugs][4300] wrong description of \pdfelapsedtime in manual
by pdftex-bugs＠sarovar.org 23 Dec '09

23 Dec '09

Bugs item #4300, was opened at 2009-12-23 10:20 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Nobody (None) Summary: wrong description of \pdfelapsedtime in manual Category: Documentation Group: None Resolution: Accepted Initial Comment: from http://www.ntg.nl/pipermail/ntg-pdftex/2009-December/003872.html: ,--------, The manual says (January 25, 2007, Rev. 1.675): | \pdfelapsedtime <read-only integer> | The command expands to a number ... \pdfelapsedtime is a integer register and therefore not expandable. It doesn't expand, it needs the help of \the or \number for `expansion'. `--------` ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4300&group_id=106

1 0

Manual: \pdfelapsedtime
by Heiko Oberdiek 22 Dec '09

22 Dec '09

Hello, The manual says (January 25, 2007, Rev. 1.675): | \pdfelapsedtime <read-only integer> | The command expands to a number ... \pdfelapsedtime is a integer register and therefore not expandable. It doesn't expand, it needs the help of \the or \number for `expansion'. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> --

1 0

[pdftex-Patches][3886] Fix for str_less_str (bug #993)
by pdftex-patches＠sarovar.org 01 Dec '09

01 Dec '09

Patches item #3886, was opened at 2009-04-06 03:38 >Status: Closed Priority: 3 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: Fix for str_less_str (bug #993) Category: None Group: None >Resolution: Accepted Initial Comment: The patch is based on pdftex-1.40.9. It fixes the bug #993 `/Names array not sorted correctly' by correcting function `str_less_str'. In theory pdfTeX can still be fooled by * invalid pdf strings and * equal destination names that only differs in the way of escaping. But both problems can be solved at macro level by passing the name argument of \pdfdest through \pdfescapestring. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-12-01 22:03 Message: included in 1.40.10 ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2009-04-06 13:14 Message: Thanh, I forgot. Thanks, also for removing the redundancy -- I am not too familiar with the "web" language. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2009-04-06 13:01 Message: Heiko, it seems the test (c2 < 32) is missing for the second string. I changed slightly your patch. It looks a bit ugly now but less redundant. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2009-04-06 04:08 Message: pdftex2.web.diff replaces pdftex.web.diff. It handles the case correctly if the octal sequence starts with a digit greater than three. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=3886&group_id=106

1 0

[pdftex-Patches][2087] Support for CMap namespaces
by pdftex-patches＠sarovar.org 01 Dec '09

01 Dec '09

Patches item #2087, was opened at 2008-08-28 08:17 >Status: Closed Priority: 3 Submitted By: Vasile Gaburici (vga) Assigned to: Nobody (None) 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: 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-Support Requests][4298] pdfTeX mit GCC für Windows kompilieren geht nicht
by pdftex-supportrequests＠sarovar.org 01 Dec '09

01 Dec '09

Support Requests item #4298, was opened at 2009-11-14 20:24 >Status: Closed Priority: 3 Submitted By: Siggi Siggi (siggi) Assigned to: Nobody (None) Summary: pdfTeX mit GCC für Windows kompilieren geht nicht Category: None Group: None >Resolution: Wont Fix Initial Comment: ch möchte gerne eine schlange Lösung zum automatisierten Erzeugen von PDF-Dateien haben - am besten indem ich .tex-Dateien konvertiere. Da pdfTeX ein schlankes Programm ist, versuchte ich den Quellcode zu kompilieren (da ich keine fertigen Binaries für Windows finden konnte). Ich kompiliere in der Umgebung MSys mit dem GCC. Dabei kommt es zuerst zum Typenkonflikt durch die erneute Deklaration des Datentyp 'Boolean' im Quellcode von pdfTeX. Wenn ich in den GCC includes die typedef auskommentiere, schreitet der Kompilierprozess weiter voran, bricht aber schließlich erneut ab mit der Meldung: http://a.imagehost.org/view/0059/cmd Kann mir jemand sagen, warum ganz unten kein Dateiname vorhanden ist, weshalb der Kompiliervorgang fehlschlägt? Unabhängig davon: Gibt es die Möglichkeit, pdfTeX komplett in eine .exe-Datei oder .dll-Datei zu kompilieren (ohne externe Bibliotheken)? Das wäre eigentlich die optimale Lösung. Grüße siggi ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-12-01 21:39 Message: Please use texlive or miktex, which includes pdftex. fwiw, compiling pdftex using minwg *is* possible, just not officially supported. If you want to build pdftex from sources, you are on your own. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=4298&group_id=106

1 0

[pdftex-Support Requests][4297] conflicting types for 'getline'
by pdftex-supportrequests＠sarovar.org 01 Dec '09

01 Dec '09

Support Requests item #4297, was opened at 2009-10-31 15:50 >Status: Closed Priority: 3 Submitted By: Bob Tennent (rdtennent) Assigned to: Nobody (None) Summary: conflicting types for 'getline' Category: Install Problem (example) Group: None Resolution: None Initial Comment: Building pdftex on a Fedora 11 system using build.sh fails: gcc -DHAVE_CONFIG_H -I. -I../../../src/texk/web2c -I.. -I../../../src/texk/web2c/.. -I../../libs/obsdcompat -I../../libs/obsdcompat/.. -I../../../src/texk/web2c/../../libs/obsdcompat -I../../../src/texk/web2c/../../libs/obsdcompat/.. -I../../../src/texk/web2c/../../libs/zlib -g -O2 -c tangleboot.c -o tangleboot.o In file included from tangleboot.c:94: tangleboot.h:34: error: conflicting types for 'getline' /usr/include/stdio.h:653: note: previous declaration of 'getline' was here tangleboot.c:2175: error: conflicting types for 'getline' /usr/include/stdio.h:653: note: previous declaration of 'getline' was here I've built pdftex often on other systems without running into this. What's wrong? ---------------------------------------------------------------------- Comment By: Bob Tennent (rdtennent) Date: 2009-11-02 15:05 Message: >| Near the end of texk/web2c/cpascal.h: #ifdef getline #undef getline #endif #define getline web2c_getline Thanks. I'd change this request to "closed" if I could figure out how :+) ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2009-11-02 14:22 Message: Near the end of texk/web2c/cpascal.h: #ifdef getline #undef getline #endif #define getline web2c_getline ---------------------------------------------------------------------- Comment By: Bob Tennent (rdtennent) Date: 2009-11-02 14:08 Message: "there is a fix for this problem in texlive 2009" That won't help those of us using a distribution like Fedora 11 which is still at texlive-2007. Editing stdio.h isn't an option for most users. And editing the source of pdftex isn't straightforward because of the conversions. What exactly is the "fix" implemented in texlive 2009? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2009-11-02 07:30 Message: POSIX 2008? That's new. It seems the glibc team likes to break old programs. http://blog.scottt.tw/2009/04/getline-is-in-posix-2008-and-exposed-in.html and numerous other hits. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2009-11-02 07:13 Message: FWIW: there is a fix for this problem in texlive 2009. ---------------------------------------------------------------------- Comment By: Bob Tennent (rdtennent) Date: 2009-11-02 03:03 Message: This is the response at the Fedora bugzilla: getline is a standard POSIX 2008 function, and glibc headers by default offer POSIX 2008 namespace. See info libc 'Feature Test Macros' for details. You should just either fix pdftex to use a different name, not reserved by POSIX 2008, or use a namespace macro that doesn't provide POSIX 2008 stuff. https://bugzilla.redhat.com/show_bug.cgi?id=532230 ---------------------------------------------------------------------- Comment By: Bob Tennent (rdtennent) Date: 2009-10-31 16:50 Message: According to some reports on the web, the problem is in glibc-2.10.1. Apparently the non-standard definition of getline there should be "protected". Indeed, if I comment out that definition in /usr/include/stdio.h, pdftex builds normally. I'm willing to file a bug report in the Fedora bugzilla but I need some help: what exactly is the "protection" needed? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=4297&group_id=106

1 0

[pdftex-Bugs][4296] No /Fit, please!
by pdftex-bugs＠sarovar.org 01 Dec '09

01 Dec '09

Bugs item #4296, was opened at 2009-10-05 12:46 >Status: Closed Priority: 3 Submitted By: Lars Hellström (lars_h) Assigned to: Nobody (None) Summary: No /Fit, please! Category: Documentation Group: v1.40.8 >Resolution: Invalid Initial Comment: In the pdfTeX manual (e.g. the ones that comes with TeXLive 2009), all links seem to be made with /Fit destinations. THIS --- shrinking the text to beneath readable size at every jump, so that one constantly has to rezoom the document in order to read it --- IS INCREDIBLY ANNOYING! For your information, it's not very difficult to preserve the zoom level: just use /XYZ with null for z (and maybe also x and y, if determining the destination location is too hard). Please stop using the extremely annoying /Fit. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-12-01 21:32 Message: sorry, this is not a bug but a matter of personal taste/opinion. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4296&group_id=106

1 0

[pdftex-Bugs][606] Forbidden ... while scanning ???
by pdftex-bugs＠sarovar.org 01 Dec '09

01 Dec '09

Bugs item #606, was opened at 2006-09-16 20:28 >Status: Closed Priority: 2 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hartmut Henkel (hhenkel) Summary: Forbidden ... while scanning ??? Category: Primitives Group: v1.40.0 >Resolution: Fixed Initial Comment: \pdftrailer {abc \bye gives ! Forbidden control sequence found while scanning text of \pdftrailer. but \pdfximage {abc \bye or \pdfliteral {abc \bye give ! Forbidden control sequence found while scanning text of ???. Instead of these three question marks there should be the name of the primitive. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2009-12-01 21:29 Message: fixed in 1.40.10 ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2009-04-07 06:28 Message: Attached is what I would do: patch scan_keyword() to restore cur_cs in the 'false' case. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-05-27 15:40 Message: Logged In: YES user_id=421 Hartmut, can you please check this again for 1.50? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-21 12:22 Message: Logged In: YES user_id=421 I've backed out the change; this is low priority and probably needs more changes. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2006-09-17 19:10 Message: Logged In: YES user_id=929 yes, the patch works, thanks a lot! But there are in fact many more \pdf... primitives that suffer from this problem, actually any with a scan_keyword call before the scan_pdf_ext_toks. After the way how it's done in @<Implement \.{\\write}@>=, it seems that a new variable save_cur_cs is not needed if one uses k for this purpose. Needs change of a few k uses to j. But problematic is \pdfoutline as it has another scan_pdf_ext_toks for the attr keyword. Wouldn't these many changes be too risky for 1.40.0? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-17 16:34 Message: Logged In: YES user_id=421 The patch was missing. Fixed. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-09-17 14:30 Message: Logged In: YES user_id=421 The cause seems to be that some scan_functions loose the meaning of cur_cs, which leads to the ??? when reaching <Tell the user what has run away...@>. The attached (IMHO crude) patch fixes this for the cases you mentioned, but there are probably other cases not found... ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=606&group_id=106

1 0