- ntg-pdftex - NTG Mailing Lists

problems still, within tounicode.c
by Ross Moore 13 Jun '17

13 Jun '17

Hi Akira, Karl Thanks for your help in sorting out how \pdfglyphtounicode allows access to upper-plane code-points. However, I think there is still a problem in how pdftex constructs the /ToUnicode CMap. This concerns characters with glyph names that use the ‘.’ qualifying construction; e.g. a.sc, b.sc , … aacute.sc , W.alt , Theta.var1 , etc. It seems that there can be entries for these glyph names within the database, but those entries are never recovered to be written into the CMap. This is because of the following coding: tounicode.sty lines 187 onwards: >> /* this function set proper values to *gp based on s; in case it returns >> * gp->code == UNI_EXTRA_STRING then the caller is responsible for freeing >> * gp->unicode_seq too */ >> static void set_glyph_unicode(char *s, glyph_unicode_entry * gp) >> { >> ... >> >> /* strip everything after the first dot */ >> p = strchr(s, '.'); >> if (p != NULL) { >> *buf = 0; >> strncat(buf, s, p - s); >> s = buf; >> } >> >> ... The origin of this coding is surely Adobe’s stated way to establish a default for which character to select for Copy/Paste, Searching, etc. *** when there is no guidance from a CMap or /ActualText entry. *** However, pdftex is making it impossible to set such CMap entries for glyphs with qualified names involving the ‘.’ character. In short, \pdfglyphtounicode allows replacement Unicode strings to be entered into the glyph-name database, but … … set_glyph_unicode never uses those entries, replacing them instead with the unqualified glyph name. The attached file explores this using the libertine-type1.sty package. (Make sure libertine.map is enabled, to use this example.) My suggestion for altering tounicode.c , within the set_glyph_unicode function block, is to test the full name (including ‘.’s) first, for a datbase entry. If found, use it. Otherwise, try again using just the prefix (as at present). Or in case a name is multiply qualified; e.g., delta.sc.ipa (occurs in cmu-tipx.enc ) also omega.sc.ipa q.sc.ipa f.sc.ipa then drop off the qualifications from the end. So test in order: delta.sc.ipa delta.sc delta Without a fix of this sort, the true small-cap characters that are in Unicode can never be properly addressed, for archival/accessibility considerations, as well as Copy/Paste. Such characters occur within blocks: U+025A — U+02FF IPA Extensions U+1D00 — U+1D7F Phonetic Extensions U+A720 — U+A7FF Latin Extended-D U+FE50 — U+FE6F Small Form Variants And of course there are superiors and inferiors in other blocks, which also are affected, when glyph names are used, such as: i.superior n.superior /zero.inferior /one.inferior etc. as is very commonly used in fonts. Cheers Ross Dr Ross Moore Mathematics Dept | 12 Wally’s Walk, 734 Macquarie University, NSW 2109, Australia T: +61 2 9850 8955 | F: +61 2 9850 8114 M:+61 407 288 255 | E: ross.moore(a)mq.edu.au http://www.maths.mq.edu.au <http://mq.edu.au/> [cid:75d17d3b-7e73-4ee3-a688-50d035309531@ausprd01.prod.outlook.com] CRICOS Provider Number 00002J. Think before you print. Please consider the environment before printing this email. This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender, and are not necessarily the views of Macquarie University.

6 7

Error with \pdfglyphtounicode when surrogates are involved.
by Ross Moore 31 May '17

31 May '17

Hi all. I’ve just discovered a problem with \pdfglyphtounicode when you are trying to map a character to a Plane-1 code-point. Here is a minimal working example that shows the issue. %%%%% cut here for test file %%%%%% \pdfcompresslevel=0 \pdfgentounicode=1 \input glyphtounicode.tex \pdfglyphtounicode{Z}{D835DC81} % MATH bold-italic-Z U+1D481 (U+D835 U+DC81) Z $Z$ \bye %%%%% end cut here for test file %%%%%% Using: This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) (preloaded format=pdftex) The two fonts both get a bad entry in their /ToUnicode CMap resource. viz. <5A> <36E537DC81> instead of the intended: <5A> <D835DC81> The Hex string <36E537DC81> is not just wrong it is actually invalid for a CMap entry, which is supposed to have a multiple of 4 Hex digits, not 10 of them. A cut&paste of the `Z`s in the PDF output produces chinese glyphs, which is usually a sign that some UTF-8 sequence has got screwed up. Of course I don’t really want to map all `Z`s into Plane-1. This is just an easy way to illustrate the problem that I discovered when trying to support proper Cut/Paste of exotic characters in LinLibertine & LinBiolinum fonts. Cheers Ross Dr Ross Moore Mathematics Dept | 12 Wally’s Walk, 734 Macquarie University, NSW 2109, Australia T: +61 2 9850 8955 | F: +61 2 9850 8114 M:+61 407 288 255 | E: ross.moore(a)mq.edu.au<mailto:ross.moore@mq.edu.au> http://www.maths.mq.edu.au [cid:image001.png@01D030BE.D37A46F0]<http://mq.edu.au/> CRICOS Provider Number 00002J. Think before you print. Please consider the environment before printing this email. This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender, and are not necessarily the views of Macquarie University.

3 9

[PATCH] pdftex - Add new \pdfpkscalable primitive
by Pali Rohár 29 May '17

29 May '17

Hi! As Karl suggested, I implemented new pdfTeX primitive for controlling if PK font specified in \pdfmapline or \pdfmapfile should be treated as scalable or not. Now by default PK fonts in mapfile/mapline are scalable. Setting value to boolean register \pdfpkscalable takes affect for followings \pdfmapfile and \pdfmapline calls. When is 1 (true) then PK fonts specified in mapfile/mapline are scalable, when 0 (false) then non-scalable (like if they are not specified in mapfile/mapline). Default value is \pdfpkscalable=1 (so behaviour like before). It is useful for specifying enc file for non scalable PK font file (as most bitmap PK fonts does not scale). In patch I defined new fm type flags F_TYPE3 and F_SCALT3FONT, so fm entry can be correctly check if is type 3 or not. Next I split behaviour of current function hasfmentry() into hasfmentry() and isscalable(). hasfmentry() returns true if font id has fm entry (like before), and isscalable() returns true if font id is scalable. In more places was used call hasfmentry() just for checking if font is scalable. Now after introducing non-scalable PK fonts in fm entry, check for scalable font cannot be done by hasfmentry(). So after this change font is *not* scalable (OR): * was not specified in \pdfmapfile or \pdfmapline * is PK Type3 and \pdfpkscalable was set to 0 prior map line processing Example for pdftex -ini: \pdfoutput=1 \catcode`\{=1 \catcode`\}=2 \pdfpkresolution=600 \hsize=4in \vsize=4in \parfillskip=0pt plus1fil \pdfcompresslevel=0 \pdfobjcompresslevel=0 \output={\shipout\box255} \input glyphtounicode \pdfgentounicode=1 \pdfmapline{} % disable all Type1 fonts \pdfpkscalable=0 \pdfmapline{cmr10 <7t.enc} \font\fa=cmr10 \fa ffi test \vskip10pt \font\fb=cmr10 at 60pt \fb ffi test \end When line with pdfmap 7t.enc is commented, then output PDF would not have Unicode definition for ffi ligature. When line \pdfpkscalable=0 is commented, then font at 60pt would look very ugly in result PDF file (just scaled \fa cmr10 with 600dpi). Suggestions or improvements to my patch are welcome! -- Pali Rohár pali.rohar(a)gmail.com

4 20

Adding support of \pdfxform to synctex
by Jérôme LAURENS 21 Apr '17

21 Apr '17

Hi there, I need some confirmation : can I assume that \pdfxform are shipped out at the very end of a regular page and that it will be the case in the future or so ? TIA

3 3

[PATCH] Remove duplicate macros set_subfont(), unset_subfont(), is_subfont()
by Pali Rohár 30 Mar '17

30 Mar '17

Hi! I found that macros set_subfont(), unset_subfont() and is_subfont() in file ptexmac.h are defined two times: ... 162 # define set_subfont(fm) ((fm)->type |= F_SUBFONT) <--- 163 # define set_type1(fm) ((fm)->type |= F_TYPE1) 164 # define set_truetype(fm) ((fm)->type |= F_TRUETYPE) 165 # define set_opentype(fm) ((fm)->type |= F_OTF) 166 # define set_subfont(fm) ((fm)->type |= F_SUBFONT) <--- ... In attachment I'm sending patch which remove duplicate definitions. -- Pali Rohár pali.rohar(a)gmail.com

2 1

Time for Type3 bitmap fonts to cause a warning?
by Markus Kuhn 29 Mar '17

29 Mar '17

Type3 bitmap fonts look much worse on most output devices than properly-hinted Type1 fonts. Type3 fonts also can cause problems with PDF interpreters in printers, which sometimes no longer implement all aspects of the Type3 language correctly. Type3 fonts were once a hack that seems no longer widely used outside the TeX community, and therefore are now less well tested and supported by device manufacturers. Type3 bitmap fonts seem an anachronism from the 1980s, when it was customary to output DVI files using Metafont-generated device-specific bitmaps, and when there were only a small number of standard output resolutions in use. Today, I find that in nearly all cases where I encounter pdftex-generated documents with Type3 bitmap fonts, these were actually selected by an inexperienced author by accident, (often as a result of copying a line such as \usepackage[T1]{fontenc} without understanding its font-selection implications). Suggestion: it would be useful to actively discourage in pdftex the use of Type3 fonts. This could be done in steps, e.g.: - initially just output a warning that prominently lists any Type3 fonts used in the PDF produced (plus add an "I know what I do and really want Type3" command-line override option to suppress that warning) - later turn that warning into an error, such that Type3 fonts can now only be included into PDFs using the "I know what I do and really want Type3" command-line option, to make sure they only appear in PDFs as a deliberate choice by an experienced author. [The idea is similar to how HTTPS browsers like Chrome or Firefox gradually added warnings to phase out outdated cryptography.] If Type3 fonts generated a clear warning, this would make it much easier for the authors of document-submission guidelines to tell PDF authors what they need to avoid. At the moment, such guidelines have to rely on more complex instructions to check font types with e.g. pdffonts file.pdf | grep 'Type 3' Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain

3 2

[PATCH v3] pdftex - Add support for encfile and \pdfgentounicode for PK fonts
by Pali Rohár 28 Mar '17

28 Mar '17

... continued thread "[pdftex] pdftex - Encoding for metafont PK fonts" This patch allows to specify encoding file also for bitmap PK fonts (generated by MetaFont) and add support for \pdfgentounicode primitive for these fonts. Example for csb12 (CSFonts, Latin 2 encoding): \nopagenumbers \pdfmapline{+csb12 <csr.enc} \pdfglyphtounicode{ccaron}{010D} \pdfgentounicode=1 \font\csb=csb12 \csb \char232 \bye Char 232 (0xE8) in font csb12 is 'č' (LATIN SMALL LETTER C WITH CARON) and glyph name for 'č' is /ccaron. Unicode character is 0+010D. Note that U+OOE8 (decimal 232) is 'è' (LATIN SMALL LETTER E WITH GRAVE) which is reason why encoding file (csr.enc) is needed. Unicode is extension of Latin 1 (character positions 127-255 are same) so this is reason why Latin 1 PK fonts works fine without encoding files... In V3 version of patch I added check for duplicate glyph names to prevent generating incorrect PDF files. Duplicates of glyph names are not used and default glyph name used by pdftex "\a<number>" is used as before. And I added small extension to pdftex-t.tex documentation as Karl Berry wanted. -- Pali Rohár pali.rohar(a)gmail.com

6 28

svn repo for pdftex now on tug.org
by Karl Berry 13 Mar '17

13 Mar '17

Hi - for the record, the subversion source repository for pdftex has been moved to tug.org, since foundry.supelec.fr is shutting down later this year. The repository was not changed, just moved, so the active work is still taking place under /branches/stable, not /trunk: E.g., svn list svn://tug.org/pdftex/branches/stable (note, the protocol is svn:// rather than http:// or anything else). Can be browsed on the web at http://tug.org/svn/pdftex/branches/stable. I minimally updated the web page (http://pdftex.org) Please continue to use the pdftex mailing list for general discussion and the ntg-pdftex mailing list for development issues. Best, Karl

1 0

Reporting bug? Need help
by Roberto Iacono 30 Aug '16

30 Aug '16

Hi, I get the following message when trying to compile a pdf with my pacthed swp 5.5: pdfTeX error: pdflatex.exe (file cmsy5.ttf) What should I do? Thanks. ************************** Roberto Iacono Associate Professor in Economics and Social Policy Norwegian University of Science and Technology (NTNU) NO-7491, Trondheim, Norway Mobile: +47-90946148 Web: ntnu.edu/employees/roberto.iacono<http://ntnu.edu/employees/roberto.iacono> **************************

1 0

pdftex - Duplicated codes ligatures in glyphtounicode.tex
by Pali Rohár 27 Jun '16

27 Jun '16

Hello, I found another problem in glyphtounicode.tex file. There are duplicate codes for ligatures, see: \pdfglyphtounicode{ff}{FB00} \pdfglyphtounicode{ffi}{FB03} \pdfglyphtounicode{ffl}{FB04} \pdfglyphtounicode{fi}{FB01} ... \pdfglyphtounicode{fl}{FB02} ... \pdfglyphtounicode{IJ}{0132} ... \pdfglyphtounicode{ij}{0133} ... ... \pdfglyphtounicode{ff}{0066 0066} \pdfglyphtounicode{fi}{0066 0069} \pdfglyphtounicode{fl}{0066 006C} \pdfglyphtounicode{ffi}{0066 0066 0069} \pdfglyphtounicode{ffl}{0066 0066 006C} \pdfglyphtounicode{IJ}{0049 004A} \pdfglyphtounicode{ij}{0069 006A} Currently pdftex use last defined value, so first definitions are useless. Can you fix it that file, so there will be only one active definitions? I see that on other places duplicate values are just commented... And why is used decomposited sequence of ascii for those ligatures instead using unicode character for each ligature? -- Pali Rohár pali.rohar(a)gmail.com

4 6

pdftex - Incorrect unicode value for dotlessj
by Pali Rohár 13 Jun '16

13 Jun '16

Hello, in file texmf/tex/generic/pdftex/glyphtounicode.tex is defined wrong unicode value for dotlessj glyph. Currently it is specified as \pdfglyphtounicode{dotlessj}{F6BE}, see: https://foundry.supelec.fr/scm/viewvc.php/trunk/source/texmf/tex/generic/pd… According to unicode standard (since 4.1.0 March 2005) dotlessj glyph has code 0237, see: http://unicode.org/charts/PDF/U0180.pdf Can you fix this code for dotlessj glyph? -- Pali Rohár pali.rohar(a)gmail.com

2 4

Validation problem with PDF files produced by pdftex
by Fabrice Popineau 09 Jun '16

09 Jun '16

Hi folks, There is a recurring problem with PDF files produced by pdftex in France. Whenever PhD thesis documents are submitted to the French national archives, they have to be validated by some automated process which relies on pdftk (apparently). And files compiled by pdftex are rejected. The problem is described here : https://groups.google.com/forum/#!topic/comp.text.pdf/ZnobgbiiDZ4 French pdftex users will have an eternal gratitude to whoever will fix this :-) Best regards, -- Fabrice Popineau ----------------------------- CentraleSupelec Département Informatique 3, rue Joliot Curie 91192 Gif/Yvette Cedex Tel direct : +33 (0) 169851950 Standard : +33 (0) 169851212 ------------------------------

7 11

Re: [NTG-pdftex] Fwd: Supressing PTEX.Fullbanner and Producer version strings
by Norbert Preining 30 Apr '16

30 Apr '16

Hi Akira, hi all, (please cc, not on the list) > (2) New primitives \pdfinfoomitdate and \pdftrailerid. > If \pdfinfoomitdate=1, date is omitted. > If \pdftrailerid{somestring}, somestring is used as the trailer. > It can be \pdftrailerid{}. I am playing with this and found that it doesn't work without problems in ini files: $ pdftex -ini ***\relax entering extended mode *\input pdftexconfig.tex (/home/norbert/tl/2016/texmf-dist/tex/generic/tex-ini-files/pdftexconfig.tex) *\pdfinfoomitdate = 1 *\pdfsuppressptexinfo = 1 *\pdftrailerid{} ! Missing { inserted. <to be read again> { <*> \pdftrailerid{ } ? *\pdftrailerid{} * So the *first* call to \pdftrailerid (and \pdfinfo the same!) fails but the second call works out. It seems that there is a problem withthe caatcode of the { which only gets set after the error handler is entered. That is current TeX Live source (svn) build. All the best Norbert (please cc, not on the list) ------------------------------------------------------------------------ PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 ------------------------------------------------------------------------

2 3

Deterministic PDFs (switch to disable addition of timestamps and random ID nonces)
by Markus Kuhn 26 Jun '15

26 Jun '15

For some applications, especially where the output of pdftex lives in any kind of version-control system, it would be extremely helpful to have a switch that causes pdftex to output deterministic PDF files. At present, there are three fields in each PDF generated by pdfTeX that change at each run on identical source files: $ pdftex '\hbox{}\vfill\eject\end' Output written on texput.pdf (1 page, 8182 bytes). $ mv texput.pdf texput2.pdf $ pdftex '\hbox{}\vfill\eject\end' Output written on texput.pdf (1 page, 8182 bytes). $ diff -a texput.pdf texput2.pdf 51,52c51,52 < /CreationDate (D:20150619105331+01'00') < /ModDate (D:20150619105331+01'00') --- > /CreationDate (D:20150619105323+01'00') > /ModDate (D:20150619105323+01'00') 76c76 < /ID [<BA26D54E6C14BF8195356C4A7162A40A> <BA26D54E6C14BF8195356C4A7162A40A>] --- > /ID [<D5B098C606C27E75987095F36CDCFED7> <D5B098C606C27E75987095F36CDCFED7>] Looking at the PDF 1.7 specification in ISO 32000 at http://wwwimages.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_20… I believe that all these non-deterministic elements are optional, and could be suppressed without violating the PDF specification: Table 317 on page 550 says that the CreatingDate entry of the document information directory is optional, and the ModDate entry is optional unless PieceInfo is present. Pdftex does not output PieceInfo, right? So ModDate is also optional here. Likewise, the ID element appears to be optional as long as the PDF document is not encrypted. For DVI mode, we have already "-output-comment ''" to suppress the addition of a timestamp. Feature request: Would it be possible to add a switch, for example a command-line option like "-deterministic-output" that suppresses the automatic addition of timestamps and random ID byte strings to the generated PDF, such that repeated runs of pdftex produce identical output? Thanks, Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain

4 9

Bug#773668: okular shows "jumping" letters in pdf documents generated using pdflatex with russian babel
by Askar Safin 21 Dec '14

21 Dec '14

Package: okular Version: 4:4.8.4-3+b1 Severity: normal Tags: l10n Steps to reproduce: * Create the following file tex.tex: \documentclass[a4paper]{article} \usepackage[russian]{babel} \begin{document} Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed ... \end{document} * pdflatex tex.tex * okular tex.pdf * Adjust zoom until you will see ugly "jumping" letters (i. e. one letter is up, and the following letter in the same word is down). For example, on my laptop with screen resolution 1600 x 900 pixels and physical size 214.8 cm x 381.9 cm zoom 100 % will go What I see? Well, "jumping" letters. I see something like this: "LOrEm IpSum DOlOr SIT AmEt ...". See screenshot: http://picpaste.com/y-gh3PH69b.png . What I expected to see? Normal beautiful text. Including [russian]{babel} is mandatory to reproduce the bug. [english]{babel} will not go. But the text itself need not to be in Russian. You don't need even \usepackage[...]{inputenc}. latex tex.tex + okular tex.dvi - no bug. latex tex.tex + dvipdfm tex.dvi + okular tex.pdf - no bug. pdflatex tex.tex + okular tex.pdf - bug. pdflatex tex.tex + evince tex.pdf - no bug. pdflatex tex.tex + transfer this tex.pdf to Windows machine + open it with Adobe Reader on Windows - no bug. TeXLive version info: ii texlive-base 2012.20120611-5 all TeX Live: Essential programs and files ii texlive-binaries 2012.20120628-4 amd64 Binaries for TeX Live ii texlive-common 2012.20120611-5 all TeX Live: Base component ii texlive-doc-base 2012.20120611-1 all TeX Live: TeX Live documentation ii texlive-extra-utils 2012.20120611-2 all TeX Live: TeX auxiliary programs ii texlive-font-utils 2012.20120611-2 all TeX Live: Graphics and font utilities ii texlive-fonts-recommended 2012.20120611-5 all TeX Live: Recommended fonts ii texlive-generic-extra 2012.20120611-2 all TeX Live: Extra generic packages ii texlive-generic-recommended 2012.20120611-5 all TeX Live: Recommended generic packages ii texlive-lang-cyrillic 2012.20120611-2 all TeX Live: Cyrillic ii texlive-latex-base 2012.20120611-5 all TeX Live: Basic LaTeX packages ii texlive-latex-extra 2012.20120611-2 all TeX Live: LaTeX supplementary packages ii texlive-latex-recommended 2012.20120611-5 all TeX Live: LaTeX recommended packages ii texlive-math-extra 2012.20120611-2 all TeX Live: Advanced math typesetting ii texlive-metapost 2012.20120611-5 all TeX Live: MetaPost (and Metafont) drawing packages ii texlive-pictures 2012.20120611-5 all TeX Live: Graphics packages and programs -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages okular depends on: ii kde-runtime 4:4.8.4-2 ii libc6 2.18-4 ii libfreetype6 2.4.9-1.1 ii libjpeg8 8d-1+deb7u1 ii libkdecore5 4:4.8.4-4+deb7u1 ii libkdeui5 4:4.8.4-4+deb7u1 ii libkio5 4:4.8.4-4+deb7u1 ii libkparts4 4:4.8.4-4+deb7u1 ii libkprintutils4 4:4.8.4-4+deb7u1 ii libkpty4 4:4.8.4-4+deb7u1 ii libokularcore1 4:4.8.4-3+b1 ii libphonon4 4:4.6.0.0-3 ii libpoppler-qt4-3 0.18.4-6 ii libqca2 2.0.3-4 ii libqimageblitz4 1:0.0.6-4 ii libqt4-dbus 4:4.8.2+dfsg-11 ii libqt4-svg 4:4.8.2+dfsg-11 ii libqt4-xml 4:4.8.2+dfsg-11 ii libqtcore4 4:4.8.2+dfsg-11 ii libqtgui4 4:4.8.2+dfsg-11 ii libsolid4 4:4.8.4-4+deb7u1 ii libspectre1 0.2.7-2 ii libstdc++6 4.7.2-5 ii phonon 4:4.6.0.0-3 ii zlib1g 1:1.2.7.dfsg-13 okular recommends no packages. Versions of packages okular suggests: ii ghostscript 9.05~dfsg-6.3+deb7u1 pn jovie <none> ii okular-extra-backends 4:4.8.4-3+b1 ii poppler-data 0.4.5-10 ii texlive-binaries 2012.20120628-4 ii unrar 1:3.9.10-1 -- no debconf information

1 0

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