- ntg-pdftex - NTG Mailing Lists

Docu: \pdfminorversion, default value
by Heiko Oberdiek 21 Sep '14

21 Sep '14

Hello, the manual for pdfTeX 1.40.15 writes in table 2, that the default value for \pdfminorversion is 4. However the description for \pdfminorversion says it's 5. I think, the latter is wrong, because pdftex --ini '\showthe\pdfminorversion\end' reports 4. Yours sincerely Heiko

3 2

Docu typo: \pdfsuppresswarningpagegroup
by Heiko Oberdiek 06 Jun '14

06 Jun '14

Hello, the file `NEWS` contains 1.40.15 as date of introduction for \pdfsuppresswarningpagegroup: pdfTeX 3.14159265-2.6-1.40.15 (TeX Live 2014) - changes: - sync with Knuth TeX 3.14159265, e-TeX 2.6 - new warning-suppression parameter \pdfsuppresswarningpagegroup But the documentation says The primitive was introduced in pdfTEX 1.40.14. Yours sincerely Heiko Oberdiek

2 1

\pdfinterwordspaceon
by Heiko Oberdiek 21 May '14

21 May '14

Hello, I try testing the new pdfTeX features with fake spaces. * Documentation-bug: \pdfinterwordspaceon (integer) \pdfinterwordspaceoff (integer) AFAIK both commands do not have parameters. * Documentation-issue: "PDF/A" looks odd with the tiny "PDF". * dummy-space.tfm, dummy-space.pfb: the font is not listed in `pdftex.map' in TL 2014-pretest. * If I add: \pdfmapline{+dummy-space <dummy-space.pfb) \pdfinterwordspaceon I get a warning: pdfTeX warning: pdftex: no GlyphToUnicode entry has been inserted yet! * Bug: \pdfmapline{+dummy-space <<dummy-space.pfb} causes: pdftex: ../../../tex-live-2014-04-01/texk/web2c/pdftexdir/writefont.c:539: write_fontdictionary: Assertion `fo->fd->builtin_glyph_names != ((void *)0)' failed. Aborted Yours sincerely Heiko Oberdiek

1 0

pdflatex includegraphics eats newline of stream
by Florian Breitwieser 10 Jan '14

10 Jan '14

Hi! pdftex is eating the last new-lines in streams included with includegraphics, when the stream has an extra new-line. Toy example; an object in the PDF image looks like this: 15 0 obj <</Length 6>>stream ABCDF endstream endobj [there are just new-lines at the end of ABCDF and in the next line]. When I include this PDF with includegraphics, the last new-line disappears, but the stream Length count does not get updated (or touched at all, as far as I can tell): 15 0 obj <</Length 6>>stream ABCDF endstream endobj This produces an error when trying to get PDF/A compliance, which is strict about stream lengths. Best, Florian

3 5

Re: [NTG-pdftex] [tlbuild] writepng.c: No transparency with PDF/A-1b
by Martin Schröder 07 Jan '14

07 Jan '14

2014/1/7 Florian Breitwieser <florian.bw(a)gmail.com>: > I am trying to create PDF/A-1b compliant documents with (pdf)LaTeX. > PDF/A-1 is based on PDF v4, however unlike the former it does not > allow transparency (and is very strict about all its rules). > > ./texk/web2c/pdftexdir/writepng.c only writes the alpha channel when > pdfminorversion is >= 4, and excludes it otherwise. Eg in line 523: > > /* alpha channel support */ > if (fixedpdfminorversion < 4 > && png_get_color_type(png_ptr(img), png_info(img)) | > PNG_COLOR_MASK_ALPHA) { > png_set_strip_alpha(png_ptr(img)); > png_copy = false; > } > > Would it be feasible to add a 'notransparency' or 'pdfa1' flag to > generate a no-transparency PDF 4 document? AFAIK it's based on 1.3 (the main addition of 1.4 is transparency), so can't you just set pdfminorversion to 3? Best Martin PS: Crossposted to the pdftex-devel list

2 1

[pdftex] New document - uxtgFEGtabZsnoi
by noreply＠sarovar.org 08 May '13

08 May '13

Project: pdftex Group: Document title: uxtgFEGtabZsnoi Document description: r0IJGb <a href="http://xsrklvdqmiwv.com/">xsrklvdqmiwv</a>, [url=http://urtcdnulnfeh.com/]urtcdnulnfeh[/url] [link=http://lnkpkwmuihbk.com/]lnkpkwmuihbk[/link] http://otfrydawtcst.com/ 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 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