- ntg-pdftex - NTG Mailing Lists

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

11 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

1 0

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 14 Jun '21

14 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 11 Jun '21

11 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 20 Jan '21

20 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