March 2017 - ntg-pdftex - NTG Mailing Lists

Incomplete CharSet causes failure with PDF/A validation
by Ross Moore 29 Jan '19

29 Jan '19

Hi all. I believe there is a problem with the way pdfTeX constructs the CharSet for a subsetted font. Not all fonts are affected, and it only shows up when attempting to validate for PDF/A. I’ve mentioned the problem to Thanh and others, but as there’s been nothing done, I’ll bring it up here, with an example that cannot be worked-around. Attached are two PDF/A documents, using Hebrew text. The main font is the “David” style font from the culmus package: DavidCLM-Medium hebart-david.pdf — produced by pdfTeX hebart-gs.pdf — produced using dvips+GS hebart-david fails PDF/A validation in one aspect only (see image): “CharSet in subset font is incomplete (font contains glyphs that are not listed)"

8 43

[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

[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