- ntg-pdftex - NTG Mailing Lists

erroneous fake spaces in letterspaced fonts
by Robert 17 Oct '24

17 Oct '24

If a font is letterspaced by a sufficiently large amount, pdftex will insert fake spaces between letters, which is obviously wrong: \pdfcompresslevel0 \pdfinterwordspaceon \letterspacefont\1\font 250 \1 AB \bye yields this: Td [(A)]TJ/F52 9.9626 Tf( )Tj/F1 9.9626 Tf 9.962 0 Td [(B)]TJ Bye, -- Robert

2 1

preserving annotations when the page doesn't change
by Karl Berry 24 Aug '23

24 Aug '23

Hello pdf(tex) gurus, I put together the whole-issue pdf for tugboat by running pdftex on the tables of contents (i.e., the covers), and including all the interior pages as a concatenated pdf. This is so I can provide a table of contents with internal links to the article. That much works fine. (Example: https://tug.org/TUGboat/tb43-3/tb135complete.pdf.) However, Thanh confirmed that all hyperlinks (and other annotations, but hyperlinks are what matter to me) are stripped from the included pdf, with no option to preserve. And indeed, there are no live links in the interior of the tb*complete.pdf files. I understand that the annotations are given in absolute coordinates, so in general they wouldn't work after inclusion. But it seems to me that in my case, they would still be accurate: including a whole-page (input) pdf as a page in the output pdf, with no transformations. Then nothing on the page has changed, so presumably the x,y coordinates on the original page are still correct. (Or does the annotation also include the PDF page number, which would indeed be different?) I gather Ulrike wrote a program and LaTeX package newpax (ctan.org/pkg/newpax) to replace the old pax, to solve this by saving and re-inserting the annotation locations. I haven't tried it yet, but in any case it would be painfully time-consuming to rewrite the plain TeX setup for the TUGboat tables of contents in LaTeX, so I'm hoping I don't have to. I've tried pdftk, cpdf, ghostscript, and other tools to combine the pdfs. Everything strips the links in the included pdf. Looking on tex.sx, there are answers suggesting Adobe and other commercial software, but a) I don't have any Adobe software and b) I don't want to rely on it for TUGboat production. So ... does anyone have any ideas of a method to get all links working? Maybe LuaTeX can somehow preserve the annotations when including a pdf? (I could get the TUGboat tocs working with plain luatex easily enough, I imagine.) Alternatively, and the real reason I'm writing to this list, maybe someone would be up for looking into pdftex and seeing if there is a way to (optionally) preserve annotations in an included pdf? So far my forays into the source have not been successful, and Thanh won't be able to look at it for some time. Thanks, Karl

2 1

\ifx equality of expanded fonts
by Robert 23 Feb '22

23 Feb '22

Hi, I don't know whether this qualifies as a bug or not, and whether anything can or even should be done about it, but at least to me the following behaviour seems somewhat unexpected: \ifx\directlua\undefined\else \def\pdffontexpand#1autoexpand{\expandglyphsinfont#1} \fi \def\test#1#2{\relax0#1 expanded, 1#2 expanded: \ifx\0\1equal\else different\fi\par} \font\0=cmr10 \font\1=cmr10 \test{ not}{ not} \pdffontexpand\1 20 20 1 autoexpand \test{ not}{} \pdffontexpand\0 20 20 1 autoexpand \font\1=cmr10 \test{}{ not} \pdffontexpand\1 20 20 1 autoexpand \test{}{} \edef\x{\meaning\0} \edef\y{\meaning\1} meaning \ifx\x\y for both: \x\else different\fi \bye As you see, the font definitions are equal (in terms of \ifx) if the first font has not been expanded before the second one is defined, but are different if the first one has been expanded first (in both cases regardless of whether the second font is expanded or not). (The real-world example is this: https://tex.stackexchange.com/questions/633441/, where Spanish babel tests whether a small caps font exists by comparing it with the upright font, which gives a wrong result if the upright font has been expanded.) (Second parenthesis: with luatex, all of the above \ifx comparisons yield unequality, but that's of course outside the scope of this list.) Best regards, -- Robert

3 2

issues with pdf(pre|ap)pendkern
by Robert 11 Aug '21

11 Aug '21

Hi, a microtype user stumbled upon some bugs with \pdfappendkern/\pdfprependkern: (1) interaction with protrusion: if a glyph has a pre- or appended kern, protrusion will not work for this glyph, as pdftex will stop scanning at the inserted kern. This is certainly wrong, as this extra kern should not be considered as explicit but as implicit (but see below). It could easily be fixed, I think, by adding the auto_kern subtype to cp_skipable: pdftex.web, l. 24375: @d cp_skipable(#) == {skipable nodes at the margins during character protrusion} ( not is_char_node(#) and ( ... or ((type(#) = kern_node) and ((width(#) = 0) or (subtype(#) = normal) or (subtype(#) = auto_kern))) ... ) ) A further question would be whether the extra kern should be skipped only, or also discarded. This, I suppose, depends on how you see the prepend/append mechanism conceptually: should it be considered as adding kerning pairs with all other glyphs in the font, or as modifying the side bearings of the glyph in question. In the first case, the kern should be discarded (and in the example below, the "A" would be protruded by 500/1000em), in the second not ("A" protruded by (500-150)/1000em). For me it would be fine either way, as microtype could then adjust it anyway... (2) interaction with discretionaries: if an explicit hyphen (or two or three) has an appended kern, the discretionary following the hyphen will be inserted /before/ the kern, so that pdftex may break the line at this point, disjoining the appended kern from the glyph and carrying it over to the beginning of the next line. (3) interaction with hyphenation: in case of hyphenation, the discretionary hyphen does not receive any pre/appended kerns at all. (This one's actually older, but I either forgot to report, or it got lost, or rejected. In that case, I apologise.) Here's an example for all three issues: \hsize=7cm \parindent=0pt \tracingoutput1 \showboxdepth\maxdimen \showboxbreadth\maxdimen \def\test#1{% \vbox to 0pt{\vrule height 1cm\hfill\vrule height 1cm \vss} \leavevmode\llap{#1 }\ignorespaces} \test1 \pdfappendkern=1 \pdfprependkern=1 \pdfprotrudechars=2 \knbccode\font`\A=150 \knaccode\font`\A=150 \lpcode\font`\A=500 \rpcode\font`\A=500 text text text text text text text text AtextA AtextA \test2 \pdfprotrudechars=0 \knbccode\font`\-=250 \knaccode\font`\-=250 text text text text text text text text text-text-text \test3 text text text text text text text text-text\-text-text \bye Best, -- Robert

2 1

letterspacefont and single-char commands
by Robert 15 Jun '21

15 Jun '21

Me again. While working on the previous report, I came across a strange bug with \letterspacefont: If the first control sequence is a single character, pdftex will abort with !pdfTeX error: pdftex (file ???+100ls): Font ???+100ls at 600 not found This does not happen with all fonts, e.g., in the following example, cmr10 would be fine, as would be changing \y to \xy: \font\x=cmr12 \letterspacefont\y\x 100 \y y \bye -- Robert

2 1

letterspacing fonts with zero fontdimen6
by Robert 12 Jun '21

12 Jun '21

Hi, some fonts neglect to specify their fontdimen 6 (I don't know whether this should be considered a bug in the respective fonts, but it's just a reality). Letterspacing these fonts does not work. This is kind of comprehensible and I'm not asking to do anything about it. However, what would be nice is if \letterspacefont could take a manually specified \fontdimen6 into account. This is for example possible with protrusion, which also doesn't work with a zero fontdimen6, but can fixed by giving a non-zero one. Here's an example (change FdSymbolB to FdSymbolA to see how it looks like with a well-behaved font): \parindent=0pt \pdfprotrudechars2 \font\x=FdSymbolB-Regular at 10pt \x \lpcode\x`b=500 bye % no protrusion \fontdimen6\x=10pt bye % protrusion fixed % here it doesn't work \letterspacefont\xy\x 300 % \fontdimen6\xy=10pt % no difference \xy bye \bye -- Robert

1 0

[PATCH] Allow dumping \pdfglyphtounicode values
by Marcel Fabian Krüger 21 Jan '21

21 Jan '21

Hi, please add support for dumping \pdfglyphtounicode assignments into the format. It seems inconsistent not to allow it and it forces a separate >200KB file to be read and parsed in every run for formats which want to enable this by default. Here is a possible implementation which has been successfully tested with an adapted version of the current LaTeX kernel. Best regards, Marcel Krüger --- source/src/texk/web2c/pdftexdir/pdftex.web | 2 + source/src/texk/web2c/pdftexdir/ptexlib.h | 2 + source/src/texk/web2c/pdftexdir/ptexmac.h | 29 +++++++++++ source/src/texk/web2c/pdftexdir/tounicode.c | 54 +++++++++++++++++++++ source/src/texk/web2c/pdftexdir/writeimg.c | 30 ------------ 5 files changed, 87 insertions(+), 30 deletions(-) diff --git a/source/src/texk/web2c/pdftexdir/pdftex.web b/source/src/texk/web2c/pdftexdir/pdftex.web index 8bddf472..2aaa7214 100644 --- a/source/src/texk/web2c/pdftexdir/pdftex.web +++ b/source/src/texk/web2c/pdftexdir/pdftex.web @@ -33020,6 +33020,7 @@ dump_int(head_tab[obj_type_ximage]); dump_int(pdf_last_obj); dump_int(pdf_last_xform); dump_int(pdf_last_ximage); +dumptounicode; end @ And restoring the pdftex data structures from the format. The @@ -33054,6 +33055,7 @@ undump_int(head_tab[obj_type_ximage]); undump_int(pdf_last_obj); undump_int(pdf_last_xform); undump_int(pdf_last_ximage); +undumptounicode; end @ We have already printed a lot of statistics, so we set |tracing_stats:=0| diff --git a/source/src/texk/web2c/pdftexdir/ptexlib.h b/source/src/texk/web2c/pdftexdir/ptexlib.h index e11ab063..b94b11ff 100644 --- a/source/src/texk/web2c/pdftexdir/ptexlib.h +++ b/source/src/texk/web2c/pdftexdir/ptexlib.h @@ -206,6 +206,8 @@ extern boolean handle_subfont_fm(fm_entry *, int); extern void glyph_unicode_free(void); extern void deftounicode(strnumber, strnumber); extern integer write_tounicode(char **, const char *, const char *); +extern void dumptounicode(void); +extern void undumptounicode(void); /* utils.c */ extern boolean str_eq_cstr(strnumber, char *); diff --git a/source/src/texk/web2c/pdftexdir/ptexmac.h b/source/src/texk/web2c/pdftexdir/ptexmac.h index 54e12159..1e86f57d 100644 --- a/source/src/texk/web2c/pdftexdir/ptexmac.h +++ b/source/src/texk/web2c/pdftexdir/ptexmac.h @@ -215,4 +215,33 @@ size_t T##_limit # define str_prefix(s1, s2) (strncmp((s1), (s2), strlen(s2)) == 0) +/* (un)dumping a string means dumping the allocation size, followed + * by the bytes. The trailing \0 is dumped as well, because that + * makes the code simpler. + */ + +#define dumpcharptr(a) \ + do { \ + integer x; \ + if (a!=NULL) { \ + x = strlen(a)+1; \ + generic_dump(x); dumpthings(*a, x); \ + } else { \ + x = 0; generic_dump(x); \ + } \ + } while (0) + +#define undumpcharptr(s) \ + do { \ + integer x; \ + char *a; \ + generic_undump (x); \ + if (x>0) { \ + a = malloc(x); \ + undumpthings(*a,x); \ + s = a ; \ + } else { s = NULL; } \ + } while (0) + + #endif /* PDFTEXMAC */ diff --git a/source/src/texk/web2c/pdftexdir/tounicode.c b/source/src/texk/web2c/pdftexdir/tounicode.c index 3d93a357..0261b8d0 100644 --- a/source/src/texk/web2c/pdftexdir/tounicode.c +++ b/source/src/texk/web2c/pdftexdir/tounicode.c @@ -475,3 +475,57 @@ integer write_tounicode(char **glyph_names, const char *tfmname, pdfendstream(); return objnum; } + +void dumptounicode(void) +{ + struct avl_traverser traverse; + size_t count; + glyph_unicode_entry *gu; + + if (glyph_unicode_tree == NULL) { + count = 0; + generic_dump(count); + return; + } + + count = avl_count(glyph_unicode_tree); + generic_dump(count); + + avl_t_init(&traverse, glyph_unicode_tree); + while (gu = avl_t_next(&traverse)) { + dumpcharptr(gu->name); + generic_dump(gu->code); + + if (gu->code == UNI_STRING) + dumpcharptr(gu->unicode_seq); + } +} + +void undumptounicode(void) +{ + glyph_unicode_entry *tmp; + size_t remaining; + + generic_undump(remaining); + + if (remaining == 0) + return; + + assert(glyph_unicode_tree == NULL); + glyph_unicode_tree = + avl_create(comp_glyph_unicode_entry, NULL, &avl_xallocator); + assert(glyph_unicode_tree != NULL); + + while (remaining--) { + void **result; + glyph_unicode_entry *gu = new_glyph_unicode_entry(); + undumpcharptr(gu->name); + generic_undump(gu->code); + + if (gu->code == UNI_STRING) + undumpcharptr(gu->unicode_seq); + + result = avl_probe(glyph_unicode_tree, gu); + assert(*result == gu); + } +} diff --git a/source/src/texk/web2c/pdftexdir/writeimg.c b/source/src/texk/web2c/pdftexdir/writeimg.c index c392df97..e3896d66 100644 --- a/source/src/texk/web2c/pdftexdir/writeimg.c +++ b/source/src/texk/web2c/pdftexdir/writeimg.c @@ -443,36 +443,6 @@ void img_free(void) /* #define undumpsizet generic_undump */ #define undumpinteger generic_undump -/* (un)dumping a string means dumping the allocation size, followed - * by the bytes. The trailing \0 is dumped as well, because that - * makes the code simpler. - */ - -#define dumpcharptr(a) \ - do { \ - integer x; \ - if (a!=NULL) { \ - x = strlen(a)+1; \ - dumpinteger(x); dumpthings(*a, x); \ - } else { \ - x = 0; dumpinteger(x); \ - } \ - } while (0) - -#define undumpcharptr(s) \ - do { \ - integer x; \ - char *a; \ - undumpinteger (x); \ - if (x>0) { \ - a = malloc(x); \ - undumpthings(*a,x); \ - s = a ; \ - } else { s = NULL; } \ - } while (0) - - - void dumpimagemeta(void) { int cur_image, img; -- 2.30.0

2 2

segfault with \pdfadjustinterwordglue
by Robert 06 Jun '20

06 Jun '20

Hi, the following causes a segfault here (TL20): \pdfadjustinterwordglue1 \unhbox0 \kern1pt \ % \end Best, -- Robert

7 14

vf font expansion bug
by Karl Berry 27 Mar '20

27 Mar '20

Hello Thanh (please ack :), and everyone else - Robert (cc'd) recently reported an "interesting" pdftex bug related to font expansion of vf files on the tex-live list. For the record, his original report is here: https://tug.org/pipermail/tex-live/2020-March/045099.html but I'll quote as needed to make this email self-contained. Sorry, it's unavoidably long. I have a proposed fix (at the end) and am hoping for some kind of confirmation that it makes sense. (I am definitely not planning to make any change here for TL20. It's not that urgent, and testing is needed.) So, Robert found a case where pdftex mixes up two expanded fonts, when virtual fonts are involved. Here is a test file vfexp.tex, slightly modified from his original so it will run with -ini: ----------------------------------------------------------------------------- \catcode`\{=1 \catcode`\}=2 \pdfoutput=1 \nonstopmode \hbadness=10000 \vsize=20pc \hsize=30pt \parfillskip=0pt plus1fil \font\1=cmr10 \font\2=bchr8t %\font\2=bchr8r \pdfmapfile{} \pdfmapline{+cmr10 CMR10 <cmr10.pfb} \pdfmapline{+bchr8r CharterBT-Roman " TeXBase1Encoding ReEncodeFont " <8r.enc <bchr8a.pfb} \pdfmapline{+bchr8r+20 CharterBT-Roman " 1.020 ExtendFont TeXBase1Encoding ReEncodeFont " <8r.enc <bchr8a.pfb} \pdfmapline{+bchr8r-20 CharterBT-Roman " 0.980 ExtendFont TeXBase1Encoding ReEncodeFont " <8r.enc <bchr8a.pfb} \pdffontexpand\1 100 100 5 %autoexpand \pdffontexpand\2 20 20 20 \pdfadjustspacing=2 \1 ABC \2 This is a paragraph with font expansion. \end ----------------------------------------------------------------------------- bchr8t is a virtual font (otherwise the problem does not happen, per the commented-out \font\2 above), and we are not using autoexpand here (bug also goes away with autoexpand), and so Robert has actual tfm files for bchr8[rt][+-]20.tfm. (I'll also attach an archive with all files to reproduce.) Here are the errors from running (avoiding useless mktextfm calls) env TEXFONTS=.: MKTEXTFM=0 pdftex -ini -file-line-error vfexp.tex now: ./vfexp.tex:12:! Font \csname\endcsname=cmr10+100 at 10.0pt not loadable: Metric (TFM) file no ./vfexp.tex:12:! Font \csname\endcsname=cmr10-100 at 10.0pt not loadable: Metric (TFM) file no ./vfexp.tex:17:! Font \csname\endcsname=bchr8r+20-100 at 10.0pt not loadable: Metric (TFM) fil ./vfexp.tex:17:! Font \csname\endcsname=bchr8r-20-100 at 10.0pt not loadable: Metric (TFM) fil The first two, about failing to make cmr10+100 and cmr10-100 at the first \pdffontexpand, are expected. (Robert, to answer one of your questions: although you're right that those fonts will never be used, and the doc is not exactly clear on this point [I'll try to improve it], the reality is that pdftex immediately tries to make fonts for the stretch/shrink limit when it processes \pdffontexpand. I don't think this could/should be changed.) At the second \pdffontexpand line, it finds bchr8t.vf, and hence bchr8r.tfm, and and the +20/-20.tfm files. All that is fine. But then, when pdftex is generating the output (pdf_hlist_out, etc.), it needs to use the expanded bchr8r. The necessary tfms all exist (included in the attached) but it erroneously uses the max shrink (-100) from the cmr10 font \1, and tries to make the nonsensical bchr8r+20-100. I don't have any particular familiarity with this part of the code, but tracing through the execution in the debugger, it seems the bug is in vf_def_font, which calls set_expand_params (which makes the fonts) with this call: set_expand_params(k, pdf_font_auto_expand[f], pdf_font_expand_ratio[pdf_font_stretch[f]], -pdf_font_expand_ratio[pdf_font_shrink[f]], pdf_font_step[f], pdf_font_expand_ratio[f]); The problem is that pdf_font_stretch[f] (and _shrink[f]) are both zero at this point. These are references to another font, i.e., null_font. But the zeroth entry of pdf_font_expand_ratio is not the zero for null_font, but the -100 for the specified cmr10 (which doesn't make sense to me, but I took it as given). FWIW, here are the various arrays at the critical point: (gdb) ppool fontname[0] $91 = "nullfont" (gdb) ppool fontname[1] $92 = "cmr10" (gdb) ppool fontname[2] $93 = "bchr8t" (gdb) ppool fontname[3] $94 = "bchr8t+20" (gdb) ppool fontname[4] $95 = "bchr8t-20" (gdb) p pdffontstretch[0]@5 $96 = {0, 0, 3, 0, 0} (gdb) p pdffontshrink[0]@5 $97 = {0, 0, 4, 0, 0} (gdb) p pdffontexpandratio[0]@5 $98 = {-100, 0, 0, 20, -20} In other places in the code, e.g., check_expand_pars, there is an explicit check for pdf_font_stretch and _shrink being null_font (= 0), so I added the same explicit checks to vf_def_font, which seemed to solve the problem. pdffonts reports the expanded/shrunken fonts used: $ pdffonts vfexp.pdf name type emb sub uni object ID ------------------------------------ ----------------- --- --- --- --------- QBBONQ+CMR10 Type 1 yes yes no 4 0 DCAQPT+CharterBT-Roman-Extend_1020 Type 1 yes yes no 5 0 OXEYKB+CharterBT-Roman-Extend_980 Type 1 yes yes no 6 0 The same call to set_expand_params is in vf_expand_local_fonts, so if the above is right, the same fix would be needed there. I could not easily figure out how to exercise that code, though. Something like a vf that refers to another vf? I'll append the full patch I have. Thanh, anyone else, confirm/deny/comments? Robert, if you're willing, I could send you a new binary (x86_64-linux?) for you to try. I presume your microtype work has more tests that could go some way toward ensuring there's no unexpected side effect. Thanks, Karl --- pdftex.web (revision 822) +++ pdftex.web (working copy) @@ -17519,13 +17519,21 @@ procedure vf_expand_local_fonts(f: internal_font_number); var lf: internal_font_number; k: integer; + shrink_limit, stretch_limit: integer; begin pdfassert(pdf_font_type[f] = virtual_font_type); for k := 0 to vf_local_font_num[f] - 1 do begin lf := vf_i_fnts[vf_default_font[f] + k]; + {Find stretch and shrink values, if any.} + if pdf_font_stretch[f] = null_font then stretch_limit := 0 + else stretch_limit := pdf_font_expand_ratio[pdf_font_stretch[f]]; + {Ditto for shrink.} + if pdf_font_shrink[f] = null_font then shrink_limit := 0 + else shrink_limit := pdf_font_expand_ratio[pdf_font_stretch[f]]; + {Now make the font(s) for |lf|.} set_expand_params(lf, pdf_font_auto_expand[f], - pdf_font_expand_ratio[pdf_font_stretch[f]], - -pdf_font_expand_ratio[pdf_font_shrink[f]], + stretch_limit, + -shrink_limit, pdf_font_step[f], pdf_font_expand_ratio[f]); if pdf_font_type[lf] = virtual_font_type then vf_expand_local_fonts(lf); @@ -17962,6 +17970,7 @@ vf_def_font s: str_number; ds, fs: scaled; cs: four_quarters; + stretch_limit, shrink_limit: integer; begin cs.b0 := vf_byte; cs.b1 := vf_byte; cs.b2 := vf_byte; cs.b3 := vf_byte; fs := store_scaled_f(vf_read_signed(4), font_size[f]); @@ -17992,9 +18001,16 @@ vf_local_font_warning(f, k, "design size mismatch"); end; if (pdf_font_step[f] <> 0) then + {Find stretch and shrink values, if any.} + if pdf_font_stretch[f] = null_font then stretch_limit := 0 + else stretch_limit := pdf_font_expand_ratio[pdf_font_stretch[f]]; + {Ditto for shrink.} + if pdf_font_shrink[f] = null_font then shrink_limit := 0 + else shrink_limit := pdf_font_expand_ratio[pdf_font_stretch[f]]; + {Now make the font(s) for |k|.} set_expand_params(k, pdf_font_auto_expand[f], - pdf_font_expand_ratio[pdf_font_stretch[f]], - -pdf_font_expand_ratio[pdf_font_shrink[f]], + stretch_limit, + -shrink_limit, pdf_font_step[f], pdf_font_expand_ratio[f]); vf_def_font := k; end;

4 9

Line breaks in pdftex log
by Pavel Sanda 07 Aug '19

07 Aug '19

Hello, I hope this is the right list for my question. The choice of pdftex log line breaks at 80 chars makes automatic parsing of errors and reporting the chosen ones by 3rd party apps unnecesarilly hard. I couldn't find any command line switch to turn this feature off (CMIIW) and using max_print_line variable is problematic (you don't want to mess with texmf.cnf as an independent app and using it as environment variable will give you headache with portability to different platforms). Would be adding command line parameter (like --max-print-line=num) or even disabling the line break by default possible in some future versions? Or is there some better option I missed? Thanks, Pavel

6 13

[NTG-context] luatex crash around page 1000
by Akira Kakuto 12 Apr '19

12 Apr '19

> The event manager says, that it is a stack exhaustion (0xc00000fd, > STATUS_STACK_OVERFLOW). Many thanks. I'll increase size of stack. Best, Akira

1 0

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

Re: [NTG-pdftex] Incomplete CharSet causes failure with PDF/A validation
by Karl Berry 28 Jan '19

28 Jan '19

Ok, now: \pdfomitcharset=0 (default) -> /CharSet included \pdfomitcharset=1 -> /CharSet omitted I warn in the pdftex documentation not to rely on other values, in case we end up ever implementing anything fancier we need a switch for. Just now committed to pdftex and TL repos. Hope it works out this time. -k

1 0

Re: [NTG-pdftex] small problems with newtx fonts
by Ross Moore 04 Oct '18

04 Oct '18

Hi all. I’ve encountered a problem whereby pdfTeX generates different subsets of the same font, containing exactly the same subsetted name. On 1 Oct 2018, at 8:36 am, Karl Berry <karl(a)freefriends.org<mailto:karl@freefriends.org>> wrote: Hi Ross, If you feel like posting the issue to the ntg-pdftex list, or coming up with a patch yourself, so much the better. A simpler test using plain TeX that just typesets two characters in two different fonts and creates the problems would be helpful, too. This coding exhibits the problem. %%% test-duplicate-fonts.tex %%% \font\fonti=fxlri-7alt \font\fontii=fxlri-7letters \font\fontiii=fxlri-7letters at 11pt {\fonti \char"03} {\fontii A B C} {\fontiii A D E} \bye %%%%% end of test-duplicate-fonts.tex %%% Using pdf fonts to see the names of embedded fonts, one gets: name type emb sub uni prob object ID ------------------------------------ ----------------- --- --- --- ---- --------- SAMSAA+LinLibertineI7 Type 1 yes yes yes 4 0 SAMSAA+LinLibertineI7 Type 1 yes yes yes 5 0 SDXKYB+CMR10 Type 1 yes yes yes 6 0 Where the 1st two entries are seen to be identical. Running Preflight checks, this duplication results in error reports as in the image. (BTW, I was using a different filename to the above coding.) [cid:286A2034-C351-4AE2-81BE-6DDBDAE8AB41@telstra.com.au] I think the issue is related to having 2 different fonts (here fxlri-7alt and fxlri-7letters from the newtx fonts ) using characters from the same base font (here LinLibertineI7 ). But this is not an error in itself. The issue must lie with how the subsetting prefix ‘SAMSAA’ is generated. Surely if the same prefix has already been used with an instance of the same font, then the next instance should increment it (e.g., to SAMSAB or SAMSAC or …., say) until a unique name is achieved. It is important to get this fixed, else many otherwise perfectly fine documents will fail Preflight validation checks, for modern PDF standards. All the best, 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<tel:%2B61%202%209850%209695> M:+61 407 288 255<tel:%2B61%20409%20125%20670> | E: ross.moore(a)mq.edu.au<mailto:rick.minter@mq.edu.au> http://www.maths.mq.edu.au<http://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.<http://mq.edu.au/> 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.<http://mq.edu.au/>

2 3

\expanded
by Joseph Wright 18 May '18

18 May '18

Hello all, As recently raised on the TeX Live mailing list, the LaTeX team feel that the \expanded primitive, suggested for pdfTeX 1.50 around 10 years ago, would be a useful addition to TeX engines. (It is present in LuaTeX.) Attached is a patch which provides the primitive itself (based on the LuaTeX version), an entry for the pdfTeX manual, and some tests. (This is based on the version in https://github.com/josephwright/texlive-source/tree/expanded, slightly adjusted as the tests there also cover other primitives to support XeTeX additions.) I have chosen the pdfTeX manual as the 'home' for documenting behaviour as the idea comes from pdfTeX and as this is usually where 'utility' primitives have been documented. A similar request has been made for XeTeX (for the code part), whilst the (u)pTeX developers already have a Git branch which would add this functionality. We (the team) do hope that general agreement can be reached to make this available in the main engines (pdfTeX, XeTeX, LuaTeX, e-pTeX, e-upTeX) for TL'19. Regards, Joseph

4 17

\\pdftexrevision is incorrectly defined
by Pali Rohár 25 Mar '18

25 Mar '18

Hi! In current pdftex.web file in stable branch is following code: http://tug.org/svn/pdftex/branches/stable/source/src/texk/web2c/pdftexdir/p… @d pdftex_version==140 { \.{\\pdftexversion} } @d pdftex_revision=="18" { \.{\\pdftexrevision} } @d pdftex_version_string=='-1.40.19' {current \pdfTeX\ version} Therefore banner is set to version 1.40.19, but \pdftexrevision just to version 18. This looks like an error. -- Pali Rohár pali.rohar(a)gmail.com

2 2

Re: [NTG-pdftex] [tex-k] e-TeX \lastnodetype initialization problem
by Akira Kakuto 24 Mar '18

24 Mar '18

Hi Hironobu, > A patch for > * etexdir/tex.ech > * pdftexdir/pdftex.ch > * xetexdir/xetex.ch > is attached. Many thanks. Applied in r47096. Best, Akira

1 0

Re: [NTG-pdftex] \pdffontobjnum assertion failed
by Hironobu Yamashita 26 Jan '18

26 Jan '18

Looking more deeply, I found that LuaTeX also causes Assertion failed: (fo->last_char>=fo->first_char), function create_fontdictionary, file ../../../texk/web2c/luatexdir/font/writefont.w, line 683. Abort trap: 6 when if (!font_has_subset(f)) return; inside do_pdf_font() is removed. Therefore, it seems that the pdfTeX issue can be avoided by applying the attached patch. Hironobu Yamashita

4 6

\pdffontobjnum assertion failed
by Karl Berry 24 Jan '18

24 Jan '18

In case anyone here has a chance to look ... Date: Tue, 23 Jan 2018 15:52:19 +0100 From: Enrico Gregorio <Enrico.Gregorio(a)univr.it> To: TeXLive <tex-live(a)tug.org> Subject: [tex-live] Bug in pdftex. Suggestions on who to report? The following example, compiled with pdftex, \edef\tenitnumber{\pdffontobjnum\tenit} \message{The font number is \tenitnumber} \tenitnumber \bye fails with This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) (preloaded format=pdftex) restricted \write18 enabled. entering extended mode (./alfon.tex{/usr/local/texlive/2017/texmf-var/fonts/map/pdftex/updmap/pdftex.m ap} The font number is 1 [1]Assertion failed: (fo->last_char >= fo->first_char), function create_fontdictionary, file ../../../texk/web2c/pdftexdir/writefont.c, line 607. )Abort trap: 6 The similar \edef\first{\pdffeedback fontobjnum\tenit} \first \bye doesnât fail on LuaTeX. Tested both on Mac OS X and Windows (Joseph Wright tested it). [...]

3 11

Re: [NTG-pdftex] \pdffontobjnum assertion failed
by Akira Kakuto 24 Jan '18

24 Jan '18

> I tired to gather similar lines: Sorry, I tried ... Best, Akira

1 0

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 20 Dec '17

20 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