January 2013 - ntg-pdftex - NTG Mailing Lists

[pdftex-Support Requests][4359] The /Names[..(hypertarget)..] is not visible in PDF 1.5 anymore
by pdftex-supportrequests＠sarovar.org 10 Jan '13

10 Jan '13

Support Requests item #4359, was opened at 2013-01-08 08:41 Status: Open Priority: 3 Submitted By: Vadim Engelson (vengelson) Assigned to: Nobody (None) Summary: The /Names[..(hypertarget)..] is not visible in PDF 1.5 anymore Category: None Group: None Resolution: None Initial Comment: The older version of pdflatex 1.40.9 generates an ASCII fragment in PDF file looking like /Names[...(HYPERTARGET)...] for each latex \hypertarget{HYPERTARGET} command in Latex *.tex file PDF version is 1.4. Using OpenSuse 11.2. In PDF these are called named-destinations. These can be visible by unix command "strings xxx.pdf" The new version of pdflatex 1.40.12 generates this information in some encoded from , not in ASCII. May be it is compressed or encoded for some reason. The PDF version 1.5 now. Using OpenSuse 12.2. Is there any extra argument, parameter or a switch to make the strings like /Names[...(HYPERTARGET)...] visible as ASCII strings inside PDF file ? If not, is there any simple API that works with PDF 1.5 on Unix, to extract all named-destinations mentioned in the PDF file ? ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2013-01-10 19:50 Message: The more recent TeX distributions (TeX Live, MiKTeX) have changed the default settings for the PDF formats: * PDF version is now PDF-1.5. * PDF object compression is enabled, a feature of PDF-1.5, that compresses objects that are not stream objects. PDF object compression can be disabled by \pdfobjcompresslevel=0 The setting for the formats is configured in `pdftexconfig.tex' in TeX Live. After changing the file you need to regenerate the format files. (Do not mix up \pdfobjcompresslevel with \pdfcompresslevel, the latter configures stream compression.) Or you can use package `pdf14' (or hyperref option `pdfversion=1.4') right at the beginning of the document (before PDF objects are written): \RequirePackage{pdf14} This is even possible (and recommended) before \documentclass. The package switches back to PDF-1.4 and disables object compression, which not available in PDF-1.4. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=4359&group_id=106

1 0

[pdftex] New document - UTrUayuWcy
by noreply＠sarovar.org 08 Jan '13

08 Jan '13

Project: pdftex Group: Document title: UTrUayuWcy Document description: vxRNaEddISWeK Submitter: Nobody (None) ------------------------------------------------------- For more info, visit: http://sarovar.org/docman/index.php?group_id=106

1 0

[pdftex-Support Requests][4359] The /Names[..(hypertarget)..] is not visible in PDF 1.5 anymore
by pdftex-supportrequests＠sarovar.org 08 Jan '13

08 Jan '13

Support Requests item #4359, was opened at 2013-01-08 08:41 Status: Open Priority: 3 Submitted By: Vadim Engelson (vengelson) Assigned to: Nobody (None) Summary: The /Names[..(hypertarget)..] is not visible in PDF 1.5 anymore Category: None Group: None Resolution: None Initial Comment: The older version of pdflatex 1.40.9 generates an ASCII fragment in PDF file looking like /Names[...(HYPERTARGET)...] for each latex \hypertarget{HYPERTARGET} command in Latex *.tex file PDF version is 1.4. Using OpenSuse 11.2. In PDF these are called named-destinations. These can be visible by unix command "strings xxx.pdf" The new version of pdflatex 1.40.12 generates this information in some encoded from , not in ASCII. May be it is compressed or encoded for some reason. The PDF version 1.5 now. Using OpenSuse 12.2. Is there any extra argument, parameter or a switch to make the strings like /Names[...(HYPERTARGET)...] visible as ASCII strings inside PDF file ? If not, is there any simple API that works with PDF 1.5 on Unix, to extract all named-destinations mentioned in the PDF file ? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=4359&group_id=106

1 0

[pdftex-Bugs][4347] "Error (202): Command token too long" output to stderr rather than stdout, without necessary info
by pdftex-bugs＠sarovar.org 02 Jan '13

02 Jan '13

Bugs item #4347, was opened at 2012-03-04 00:34 Status: Open Priority: 3 Submitted By: Ben Crowell (bcrowell) Assigned to: Nobody (None) Summary: "Error (202): Command token too long" output to stderr rather than stdout, without necessary info Category: PDF inclusion Group: v1.40.8 Resolution: None Initial Comment: Recent versions of pdftex sometimes print the error message "Error (202): Command token too long" to stderr. Since the message is not interleaved with pdtex's other output, and the message comes without any context, it becomes difficult or impossible for the user to know what is causing the error or what it means. This has been discussed on stackexchange: http://tex.stackexchange.com/questions/42348/pdflatex-command-token-too-lon… Based on this discussion, it sounds like this occurs when the poppler library is trying to parse a pdf file as input and doesn't like it. I don't know if it's poppler itself that is printing messages to stderr; if so, then this is a bug in poppler, not pdftex. (A library shouldn't be doing I/O to stderr.) I realize that this would be a more helpful bug report if I could provide an example of a pdf file that was causing the error, but this is occurring for me on a file that pulls in a large number of pdf images, and I don't have time right now to figure out which one is the problem. pdfTeX 3.1415926-1.40.10-2.2 (TeX Live 2009/Debian) kpathsea version 5.0.0 Copyright 2009 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). There is NO warranty. Redistribution of this software is covered by the terms of both the pdfTeX copyright and the Lesser GNU General Public License. For more information about these matters, see the file named COPYING and the pdfTeX source. Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Compiled with libpng 1.2.46; using libpng 1.2.46 Compiled with zlib 1.2.3.4; using zlib 1.2.3.4 Compiled with poppler version 0.16.7 ---------------------------------------------------------------------- Comment By: Robert Muil (robertmuil) Date: 2013-01-03 08:58 Message: I get this also, and I have a reference PDF to attach. The PDF also generates the error when opened with epdfview or evince or converted with pdftotex, so it seems certain it's a poppler issue. Rob. PS. can't work out how to attach to this system, so here's an external link: http://www.wuala.com/robertmuil/News/Public/stimulus_category_influence_on_… ---------------------------------------------------------------------- Comment By: Ben Crowell (bcrowell) Date: 2012-03-04 05:15 Message: I can't attach the figure. Stackexchange user ryan0270 is the one who has that. In my own case, I can't tell (easily) which of the hundreds of figures in my project is the one causing this. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2012-03-04 05:04 Message: please attach figures/Jan25/svdDir_svdCompare1.pdf ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4347&group_id=106

1 0