- ntg-pdftex - NTG Mailing Lists

non-pdf special ignored: <special>
by Karl Berry 06 Jan '18

06 Jan '18

For ages now, I've been wishing that pdftex output the non-pdf special it complains about finding. Often it's obvious, but sometimes it's not, and why not report it? Does anyone see a problem with this? All I can imagine is that scripts trying to parse the output might be unhappy. So we can keep the original error message unchanged, exclamation point and all, and just add the special text. As in something like the below (not tested). Probably better to truncate the special text instead of printing the whole thing, as it could be annoyingly long, but I'm wondering about the general idea. Wdyt? --thanks, karl. --- pdftex.web (revision 791) +++ pdftex.web (working copy) @@ -16257,8 +16257,12 @@ if not (str_in_str(s, "PDF:", 0) or str_in_str(s, "pdf:", 0)) then begin if warn and not (str_in_str(s, "SRC:", 0) or str_in_str(s, "src:", 0) - or (length(s) = 0)) then + or (length(s) = 0)) then begin print_nl("Non-PDF special ignored!"); + print_nl("<special> "); + slow_print(s); + print_ln; + end; return; end; j := j + length("PDF:");

2 1

[PATCH v4] Allow .enc files for bitmap PK fonts
by Pali Rohár 02 Jan '18

02 Jan '18

Hi! I'm sending new series of patches for PK fonts which are reworked on top of current texlive trunk svn repository. I split changes into more patch files and updated also documentation with test. Karl, can you look at them? -- Pali Rohár pali.rohar(a)gmail.com

3 14

Using CFF (Type 1C) instead of Type 1 fonts
by Markus Kuhn 19 Dec '17

19 Dec '17

PDFs produced by pdftex can shrink significantly in size when processed through ghostscript's pdfwrite driver. I understand a main reason for that is that ghostscript converts any Type 1 fonts that it finds into CFF (aka Type 1C) fonts. I also understand that - Type 1 fonts are eexec-encrypted, and such ciphertext cannot benefit from PDF's (de)flate compression. - CFF fonts, on the other hand, are a compacter plain-text format and compress well. - CFF fonts are also compatible with Type1, i.e. it is possible to convert any Type 1 font into a CFF font without loss of information. Is all of this correct? If so, isn't the continued use of Type 1 fonts in the TeX ecosystem an anachronism? Shouldn't TeXLive ship instead CFF/Type 1C versions of the BlueSky Computer Modern fonts and shouldn't tools like pdftex switch to using them directly? Has someone looked into what would be involved with a Type 1 to CFF migration for pdftex? It seems at the moment, pdftex is actually replacing any Type 1C glyphs that it finds in a PDF file embedded with \pdfximage with the much less space-efficient Type 1 glyphs that it find in its font map files. Has there been any progress on this since: https://tex.stackexchange.com/questions/38145/why-does-pdflatex-produce-big… ? Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain

4 5

Minor patch to pdftex.web to make it weave-able
by Shreevatsa R 10 Oct '17

10 Oct '17

Hi pdftex developers, Please consider the attached patch file for pdftex.web, which should not have any functional change. I know that pdftex.web is mainly compiled through web2c these days. So although written as an extension of tex.web it is not "really" intended as being in the WEB language, as tex.web once was. So one cannot expect the WEB tools to work on it. Still, it would be nice to run weave on it, especially since the changes needed are so minor (attached) and don't affect the web2c conversion (as far as I can tell). Specifically: 1. In one place, a module (section) name contains |goto found|| instead of |goto found| 2. In another place, a few lines of Pascal code are commented out with { ... } inside which weave expects valid TeX; instead they can be commented out with @{ ... @} or deleted altogether if appropriate. Regards, Shreevatsa

2 3

Mailing list moderator wanted
by Taco Hoekwater 25 Sep '17

25 Sep '17

Hi all, For a few years now, I have had just about nothing to do with pdftex development. But at the moment I am still the moderator of this (ntg-pdftex(a)ntg.nl) development mailing list, and I would like to get rid of this responsibility. There is very little actual work involved (you need to delete half a dozen spam messages from the moderation queue once a week, and occasionally approve a new subscription). Unfortunately, I have quite a few of these tiny tasks in my inbox, and it getting to be a big nuisance juggling them all. If you are reading this and can spare a minute each week, please send me a short note. Best wishes, Taco

1 0

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