Missing letters and numbers in printout
Hello, I have a document that includes some grids (drawn with \grid) as well as alphanumeric information (letters and numbers) which contents (the info, not the grids) I modify every year and then print it out. I've been using it without any problem for a few (maybe 4 or 5) years but, this time, only the grid showed up on the printout, but none of the letters or numbers would, using the same printer I used every time before. I always copy the PDF file into a USB stick that I bring to the (departamental) printer, plug it in the printer and directly print from it. I tried printing the same file (from the same USB drive) into a different printer, this time connected to a computer, and sending the file from it, which worked just fine. My guess is that the first printer in missing the font the document uses, whereas the second printer received the font from the computer (Devuan Linux), which has the appropriate font. Could that be correct? In all previous ocasions I used the version of ConTeXt included in Texlive on Devuan, but a few months ago I decided to install ConTeXt using the official distribution instead. Could that explain the change in behaviour I'm seeing? Could it be that the previous versions I used somehow embeded the fonts into the PDF file but the current one doesn't? And, if that's really the case, how could I force the font to be included into the PDF file? I remember I read something like that a very long time ago (probably about LaTeX, not ConTeXt), but I haven't found how to do it now in a few searches on the documentation. Thak you for any help or advice. Cheers, Ángel
Hello,
I have a document that includes some grids (drawn with \grid) as well as alphanumeric information (letters and numbers) which contents (the info, not the grids) I modify every year and then print it out. I've been using it without any problem for a few (maybe 4 or 5) years but, this time, only the grid showed up on the printout, but none of the letters or numbers would, using the same printer I used every time before. I always copy the PDF file into a USB stick that I bring to the (departamental) printer, plug it in the printer and directly print from it.
I tried printing the same file (from the same USB drive) into a different printer, this time connected to a computer, and sending the file from it, which worked just fine. My guess is that the first printer in missing the font the document uses, whereas the second printer received the font from the computer (Devuan Linux), which has the appropriate font. Could that be correct?
In all previous ocasions I used the version of ConTeXt included in Texlive on Devuan, but a few months ago I decided to install ConTeXt using the official distribution instead. Could that explain the change in behaviour I'm seeing? Could it be that the previous versions I used somehow embeded the fonts into the PDF file but the current one doesn't? And, if that's really the case, how could I force the font to be included into the PDF file? I remember I read something like that a very long time ago (probably about LaTeX, not ConTeXt), but I haven't found how to do it now in a few searches on the documentation. i assume that you use mkiv or lmtx in which case fonts are embedded in
On 9/26/2022 4:06 PM, Angel M Alganza via ntg-context wrote: the pdf file ... does the viewer show the file ok? Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On Mon, Sep 26, 2022 at 04:54:31PM +0200, Hans Hagen via ntg-context wrote:
i assume that you use mkiv or lmtx in which case fonts are embedded in
I guess I'm using LMTX, but I don't know how to tell for sure, since I downloaded the installer from https://wiki.contextgarden.net/Installation for Linux and a previous version for OpenBSD 32bits as well (unfortunately there isn't one now anymore) and install it from it.
the pdf file ... does the viewer show the file ok?
I thought I should have said that as soon as I pressed "y" (send in Mutt :-) on my original email. Yes, MuPDF shows the complete file without any problem, all letters and numbers are there, as well as in the printout I got from printing from a coworker computer (Devuan) to their printer. Ángel
On 9/26/22 16:06, Angel M Alganza via ntg-context wrote:
Hello,
Hi Ángel,
[...] I tried printing the same file (from the same USB drive) into a different printer, this time connected to a computer, and sending the file from it, which worked just fine. My guess is that the first printer in missing the font the document uses, whereas the second printer received the font from the computer (Devuan Linux), which has the appropriate font. Could that be correct?
From my experience, this is possible, but maybe not highly probable. By default, ConTeXt includes fonts by default, as far as I can remember (I have been using it for over a decade).
In all previous ocasions I used the version of ConTeXt included in Texlive on Devuan, but a few months ago I decided to install ConTeXt using the official distribution instead. Could that explain the change in behaviour I'm seeing? Could it be that the previous versions I used somehow embeded the fonts into the PDF file but the current one doesn't?
Again, I’d very surprised if that were the case. BTW, is TeX Gyre Heros the font with missing chars in the printed version of your PDF document? I think that your printer is having issues with the embedded font in your PDF document. There might be a workaround (or a way of testing this), compiling the PDF document with LuaTeX instead of with LuaMetaTeX. If you compile it invoking "context source.tex", use "context --luatex source.tex". It might be that your printer has problems with the way LuaMetaTeX embeds the fonts in the PDF (while it has none with LuaTeX). But the way to know for sure which tools generated your PDF document and whether fonts are embedded, "pdfinfo your-file.pdf" and "pdffonts your-file.pdf" are your friends. Both infos for the following source: \setupbodyfont[helvetica] \starttext \input zapf \stoptext $ pdffonts a.pdf name type encoding emb sub uni object ID --------------------- ------------ ------------ --- --- --- --------- TeXGyreHeros-Regular CID Type 0C Identity-H yes yes yes 1 0 $ pdfinfo a.pdf Title: a Creator: LuaMetaTeX 2.10 20220918 + ConTeXt LMTX 2022.09.11 20:44 Producer: LuaMetaTeX-2.10 CreationDate: Mon Sep 26 18:29:02 2022 CEST ModDate: Mon Sep 26 18:29:02 2022 CEST Tagged: no UserProperties: no Suspects: no Form: none JavaScript: no Pages: 1 Encrypted: no Page size: 595.276 x 841.89 pts (A4) Page rot: 0 File size: 7531 bytes Optimized: no PDF version: 1.7 Otherwise, the only option about your documents is guessing. Just in case it might help, Pablo
On Mon, Sep 26, 2022 at 07:10:40PM +0200, Pablo Rodriguez via ntg-context wrote:
BTW, is TeX Gyre Heros the font with missing chars in the printed version of your PDF document?
It doesn't seem to be that: $ pdffonts a6.pdf name type encoding emb sub uni object ID ------------------------------------ ----------------- ---------------- --- --- --- --------- KBVQDT+LMRoman8-Regular CID Type 0C Identity-H yes yes yes 2 0 PISBZT+LMRoman6-Regular CID Type 0C Identity-H yes yes yes 3 0 VGDDRM+LMRoman12-Regular CID Type 0C Identity-H yes yes yes 9 0 BBBAHN+LMMono8-Regular CID Type 0C Identity-H yes yes yes 10 0
There might be a workaround (or a way of testing this), compiling the PDF document with LuaTeX instead of with LuaMetaTeX.
It seems it is compiled with LuaTeX: $ pdfinfo a6.pdf Title: a6 Creator: LuaMetaTeX 2.09 20220429 + ConTeXt LMTX 2022.05.11 11:36 Producer: LuaMetaTeX-2.09 CreationDate: Tue Sep 20 07:19:29 2022 CEST ModDate: Tue Sep 20 07:19:29 2022 CEST Tagged: no UserProperties: no Suspects: no Form: none JavaScript: no Pages: 1 Encrypted: no Page size: 595.276 x 841.89 pts (A4) Page rot: 0 File size: 25630 bytes Optimized: no PDF version: 1.7
If you compile it invoking "context source.tex", use "context --luatex source.tex".
When I try that I get: $ context --luatex a6lua.tex mtx-context | redirect luametatex -> luatex: luatex --luaonly "/mnt/tex/tex/texmf-linux-64/bin/mtxrun.lua" --script mtx-context --luatex a6lua.tex --redirected mtxrun | unknown script 'mtx-context.lua' or 'mtx-mtx-context.lua'
But the way to know for sure which tools generated your PDF document and whether fonts are embedded, "pdfinfo your-file.pdf" and "pdffonts your-file.pdf" are your friends.
I didn't know any of the poppler-utils, thank you!
Otherwise, the only option about your documents is guessing.
I guess. :-) Ángel
On 9/26/2022 8:26 PM, Angel M Alganza via ntg-context wrote:
I didn't know any of the poppler-utils, thank you!
mtxrun --script pdf --info oeps.pdf mtxrun --script pdf --fonts oeps.pdf the second one also shows what characters are in there Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On Mon, Sep 26, 2022 at 10:44:55PM +0200, Hans Hagen via ntg-context wrote:
mtxrun --script pdf --info oeps.pdf
$ mtxrun --script pdf --info a6.pdf mtx-pdf | filename > a6.pdf mtx-pdf | pdf version > 1.7 mtx-pdf | major version > 1 mtx-pdf | minor version > 7 mtx-pdf | number of pages > 1 mtx-pdf | title > a6 mtx-pdf | creator > LuaMetaTeX 2.09 20220429 + ConTeXt LMTX 2022.05.11 11:36 mtx-pdf | producer > LuaMetaTeX-2.09 mtx-pdf | author > <unset> mtx-pdf | creation date > D:20220920071929+02'00' mtx-pdf | modification date > D:20220920071929+02'00' mtx-pdf | cropbox > pages: 1-1, width: 841.889758, height: 595.27559
mtxrun --script pdf --fonts oeps.pdf
$ mtxrun --script pdf --fonts a6.pdf mtx-pdf | id basefont encoding subtype unicode characters mtx-pdf | mtx-pdf | Fm1.F1 KBVQDT+LMRoman8-Regular no encoding Type0 no vector , - A B C D F G H I J K L M N O P R S T V Z a b c d e f g h i j k l m n o p q r s t u v x y z Á á é í ñ ó ú mtx-pdf | Fm1.F2 PISBZT+LMRoman6-Regular no encoding Type0 no vector M a d e i l n mtx-pdf | Fm2.F1 KBVQDT+LMRoman8-Regular no encoding Type0 no vector , - A B C D F G H I J K L M N O P R S T V Z a b c d e f g h i j k l m n o p q r s t u v x y z Á á é í ñ ó ú mtx-pdf | Fm3.F1 KBVQDT+LMRoman8-Regular no encoding Type0 no vector , - A B C D F G H I J K L M N O P R S T V Z a b c d e f g h i j k l m n o p q r s t u v x y z Á á é í ñ ó ú mtx-pdf | Fm4.F3 VGDDRM+LMRoman12-Regular no encoding Type0 no vector 0 2 3 mtx-pdf | Fm4.F4 BBBAHN+LMMono8-Regular no encoding Type0 no vector 0 1 2 3 4 5 6 7 8 9 A D F J M N O S a b c e g h i l m n o p r s t u v y mtx-pdf | Does that help? Ángel
On 9/26/2022 11:04 PM, Angel M Alganza via ntg-context wrote:
On Mon, Sep 26, 2022 at 10:44:55PM +0200, Hans Hagen via ntg-context wrote:
mtxrun --script pdf --info oeps.pdf
$ mtxrun --script pdf --info a6.pdf mtx-pdf | filename > a6.pdf mtx-pdf | pdf version > 1.7 mtx-pdf | major version > 1 mtx-pdf | minor version > 7 mtx-pdf | number of pages > 1 mtx-pdf | title > a6 mtx-pdf | creator > LuaMetaTeX 2.09 20220429 + ConTeXt LMTX 2022.05.11 11:36 mtx-pdf | producer > LuaMetaTeX-2.09 mtx-pdf | author > <unset> mtx-pdf | creation date > D:20220920071929+02'00' mtx-pdf | modification date > D:20220920071929+02'00' mtx-pdf | cropbox > pages: 1-1, width: 841.889758, height: 595.27559
mtxrun --script pdf --fonts oeps.pdf
$ mtxrun --script pdf --fonts a6.pdf mtx-pdf | id basefont encoding subtype unicode characters mtx-pdf | mtx-pdf | Fm1.F1 KBVQDT+LMRoman8-Regular no encoding Type0 no vector , - A B C D F G H I J K L M N O P R S T V Z a b c d e f g h i j k l m n o p q r s t u v x y z Á á é í ñ ó ú mtx-pdf | Fm1.F2 PISBZT+LMRoman6-Regular no encoding Type0 no vector M a d e i l n mtx-pdf | Fm2.F1 KBVQDT+LMRoman8-Regular no encoding Type0 no vector , - A B C D F G H I J K L M N O P R S T V Z a b c d e f g h i j k l m n o p q r s t u v x y z Á á é í ñ ó ú mtx-pdf | Fm3.F1 KBVQDT+LMRoman8-Regular no encoding Type0 no vector , - A B C D F G H I J K L M N O P R S T V Z a b c d e f g h i j k l m n o p q r s t u v x y z Á á é í ñ ó ú mtx-pdf | Fm4.F3 VGDDRM+LMRoman12-Regular no encoding Type0 no vector 0 2 3 mtx-pdf | Fm4.F4 BBBAHN+LMMono8-Regular no encoding Type0 no vector 0 1 2 3 4 5 6 7 8 9 A D F J M N O S a b c e g h i l m n o p r s t u v y mtx-pdf |
Does that help? looks ok to me
Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On 9/26/22 23:04, Angel M Alganza via ntg-context wrote:
On Mon, Sep 26, 2022 at 10:44:55PM +0200, Hans Hagen via ntg-context wrote:
mtxrun --script pdf --info oeps.pdf [...] mtx-pdf | creation date > D:20220920071929+02'00' mtx-pdf | modification date > D:20220920071929+02'00' mtx-pdf | cropbox > pages: 1-1, width: 841.889758, height: 595.27559
Hans, many thanks for the pdf script in mtxrun. I have two suggestions: 1. Would it be possible that dates could be in a more friendly format such as the following one? creation date > 2022-09-20 07:19:29 +02:00 2. Would it be possible that page dimensions would be in mm (or cm), with an option for other length units? Many thanks for your help, Pablo
On 9/26/2022 8:26 PM, Angel M Alganza via ntg-context wrote:
I didn't know any of the poppler-utils, thank you!
Otherwise, the only option about your documents is guessing. mtxrun --script pdf --info oeps.pdf
mtxrun --script pdf --fonts oeps.pdf the second one also shows what characters are in there ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On 9/26/22 20:26, Angel M Alganza via ntg-context wrote:
On Mon, Sep 26, 2022 at 07:10:40PM +0200, Pablo Rodriguez via ntg-context wrote: [...]
There might be a workaround (or a way of testing this), compiling the PDF document with LuaTeX instead of with LuaMetaTeX.
It seems it is compiled with LuaTeX:
$ pdfinfo a6.pdf Title: a6 Creator: LuaMetaTeX 2.09 20220429 + ConTeXt LMTX 2022.05.11 11:36 Producer: LuaMetaTeX-2.09
No, this was compiled with LuaMetaTeX.
If you compile it invoking "context source.tex", use "context --luatex source.tex".
When I try that I get:
$ context --luatex a6lua.tex [...] mtxrun | unknown script 'mtx-context.lua' or 'mtx-mtx-context.lua'
In that case, run "context --luatex --generate" first and then "context --luatex a6lua.tex". This would give you a pure LuaTeX-compiled PDF document. I think that this PDF document will be fine with your printer. I hope it helps, Pablo
On Tue, Sep 27, 2022 at 04:03:06PM +0200, Pablo Rodriguez via ntg-context wrote:
Producer: LuaMetaTeX-2.09 No, this was compiled with LuaMetaTeX.
It looks so obvious now, but it didn't (to me) before. :-)
In that case, run "context --luatex --generate" first and then "context --luatex a6lua.tex".
Excellent, thank you!
This would give you a pure LuaTeX-compiled PDF document. I think that this PDF document will be fine with your printer.
I'll let you know tomorrow, when I'll try printing it out on the rebel printer. Thanks! Ángel
On Tue, Sep 27, 2022 at 04:03:06PM +0200, Pablo Rodriguez via ntg-context wrote:
In that case, run "context --luatex --generate" first and then "context --luatex a6lua.tex".
This would give you a pure LuaTeX-compiled PDF document.
I think that this PDF document will be fine with your printer.
It was. I printed it this morning without any problem. Thank you! If compiling with --luatex option seem to have more chances to produce a complete product, shouldn't it be convenient for this option to be the default? I would expect 'context file.tex' to work "out of the box" and produce a correct and complete PDF output. Would it be possible to have that changed? Or is there maybe any other potentially undesirable side effect? Also, I guess that can be configured somehow so, what would need to be changed to have 'context file.txt' to compile using luatex instead of LuaMetaTeX? Thank you! Cheers, Ángel
On 9/28/2022 3:30 PM, Angel M Alganza via ntg-context wrote:
On Tue, Sep 27, 2022 at 04:03:06PM +0200, Pablo Rodriguez via ntg-context wrote:
In that case, run "context --luatex --generate" first and then "context --luatex a6lua.tex".
This would give you a pure LuaTeX-compiled PDF document.
I think that this PDF document will be fine with your printer.
It was. I printed it this morning without any problem. Thank you!
If compiling with --luatex option seem to have more chances to produce a complete product, shouldn't it be convenient for this option to be the default? I would expect 'context file.tex' to work "out of the box" and produce a correct and complete PDF output. Would it be possible to have that changed? Or is there maybe any other potentially undesirable side effect?
Also, I guess that can be configured somehow so, what would need to be changed to have 'context file.txt' to compile using luatex instead of LuaMetaTeX? top line:
% engine=luatex but lmtx is and will stay as default (btw, you don't run the latest greatest) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On Wed, Sep 28, 2022 at 03:59:07PM +0200, Hans Hagen via ntg-context wrote:
changed to have 'context file.txt' to compile using luatex instead of LuaMetaTeX? top line:
% engine=luatex
Thank you, I'll add that to my source files from now on.
but lmtx is and will stay as default
To bad the default won't work as spected (it did before or, at least with Texlive distribution,) sometimes, for some people or for some of their files.
(btw, you don't run the latest greatest)
No, alas I do not. Could you please point me to where I could download the latest greatest for 32bits OpenBSD from. I remember a discussion a few months ago to eliminated 32bits OpenBSD if nobody used it, where I asked to keep publising it if it was possible. I don't know if it has finally been removed or not, but I can't find it anywhere. Cheers, Ángel
On 9/29/2022 3:54 PM, Angel M Alganza via ntg-context wrote:
No, alas I do not. Could you please point me to where I could download the latest greatest for 32bits OpenBSD from. I remember a discussion a few months ago to eliminated 32bits OpenBSD if nobody used it, where I asked to keep publising it if it was possible. I don't know if it has finally been removed or not, but I can't find it anywhere. openbsd is tricky in the sense that ervery update means that we need to install a new vm
what you can try is to download the installation from git (contextgarden) and then compile yuourself (not that hard); ther eis a smake script that should move the bin to the right spot (nice test case for Mojca who made that setup) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On 9/29/22 15:54, Angel M Alganza via ntg-context wrote:
On Wed, Sep 28, 2022 at 03:59:07PM +0200, Hans Hagen via ntg-context wrote: [...]
but lmtx is and will stay as default
Too bad the default won't work as expected (it did before or, at least with TeXLive distribution,) sometimes, for some people or for some of their files.
Hi Ángel, there is nothing that prevents this to be fixed (as far as I know). TeXLive is still using LuaTeX as default for ConTeXt. This will be hopefully changed in next release of TeX Live (according to https://mailman.ntg.nl/pipermail/ntg-context/2022/106829.html by Hans himself). The following code relates to an issue I had with ConTeXt myself: \setuppapersize[A5][A4, landscape] \doifmodeelse{broken-printer} {\setuparranging[2UP,doublesided] \setupinteractionscreen[option={portrait, paper}]} {\setuparranging[2UP] \setupinteractionscreen[option={landscape, paper}]} \starttext \dorecurse{32} {\input knuth\par} \stoptext In a copyshop I used to go (more than four years ago), they had a printer that didn’t understand duplex printing when pages were in landscape orientation. The guy of the copyshop was a really nice person, but I didn’t want to bother him with https://opensource.adobe.com/dc-acrobat-sdk-docs/standards/pdfstandards/pdf/.... The printout was wrong, since page was flipped on the long edge. Only the other duplex printing option (besides Simplex) worked with that printer. The bug was clear on the printer interpreter. I thought of writing to the printer manufacturer so that they fix their printers. But it wasn’t worth the effort. In your case, I don't know why LMTX generated documents misbehave with the PDF interpreter from your printer. It might be that font embedding is flawed, or that the interpreter is at fault. But unless you find out which code is wrong here, you may experience issues, but there is nothing to fix in this case. Sorry for repeating myself, but you know way better than mine that this is code and it requires (a lot of) analysis to find the cause here. Just in case it helps, Pablo
On 9/28/22 15:30, Angel M Alganza via ntg-context wrote:
On Tue, Sep 27, 2022 at 04:03:06PM +0200, Pablo Rodriguez via ntg-context wrote:
[...] I think that this PDF document will be fine with your printer.
It was. I printed it this morning without any problem. Thank you!
Glad to read it helped, Ángel. I had the suspicion, because font embedding seems to be changed in LMTX. There have been minor issues in the past with this (I cannot recall whether I experienced one or two myself).
If compiling with --luatex option seem to have more chances to produce a complete product, shouldn't it be convenient for this option to be the default?
Well, that is probably too much to say (I mean, that "--luatex" generates more accurate PDF documents). What you are experiencing might be a pretty extreme case. And you are taking for granted that the PDF interpreter from your printer is 100% accurate (which might not be the case). The PDF specification deals with font embedding (to the best of my knowledge) at https://opensource.adobe.com/dc-acrobat-sdk-docs/standards/pdfstandards/pdf/.... Unless the code to be fixed (or even adapted) can be detected and improved, there is nothing to do here.
I would expect 'context file.tex' to work "out of the box" and produce a correct and complete PDF output. Would it be possible to have that changed? Or is there maybe any other potentially undesirable side effect?
The main issue would be pretending to use with LuaTeX some features available only in LuaMetaTeX.
Also, I guess that can be configured somehow so, what would need to be changed to have 'context file.txt' to compile using luatex instead of LuaMetaTeX?
I agree with Hans that LuaMetaTeX is here to stay. He may correct me, but as far as I understand it, LuaMetaTeX is LuaTeX-2.0. I hope it might help, Pablo
On 9/28/2022 5:10 PM, Pablo Rodriguez via ntg-context wrote:
Well, that is probably too much to say (I mean, that "--luatex" generates more accurate PDF documents).
depends on how one defines accurate
The main issue would be pretending to use with LuaTeX some features available only in LuaMetaTeX.
plenty (also font features) not in luatex indeed
I agree with Hans that LuaMetaTeX is here to stay. He may correct me, but as far as I understand it, LuaMetaTeX is LuaTeX-2.0. 2.10
Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
participants (4)
-
Angel M Alganza -
Hans Hagen -
Hans Hagen -
Pablo Rodriguez