2

System in use for experiments: Debian buster (i386), vanilla TeX Live 2020

Creating .dvi-files with LuaLaTeX currently appears to have no practical use to me as end-user as long as due to the lack of open-type-font-support no .dvi-viewer can display them properly and no converter (like xdvipdfmx) can convert them properly.

Please don't misunderstand me: As there are development builds of xdvipdfmx with some initial support for luatex dvi, LuaLaTeX's .dvi-files are not pointless for developers at all.

Be that as it may: Playing around with these .dvi-files is interesting.

When using LuaLaTeX in .dvi-mode for compiling the MWE

\documentclass{article}
\begin{document}
Hello World!
\end{document}

, which is saved as test.tex, i.e., when doing lualatex --output-format=dvi test.tex, then a file test.dvi is created without error-messages.

Applying dviasm test.dvi -o testluadvidump.txt for creating a human-readable dump-file yields testluadvidump.txt:

[preamble]
id: 2
numerator: 25400000
denominator: 473628672
magnification: 1000
comment: ' LuaTeX output 2021.02.08:1924'

[postamble]
maxv: 633pt
maxh: 407pt
maxs: 3
pages: 1

[font definitions]
fntdef: [/usr/local/texlive/2020/texmf-dist/fonts/opentype/public/lm/lmroman10-regular.otf] at 10pt

[page 1 0 0 0 0 0 0 0 0 0]
push:
  xxx: 'header=l3backend-dvips.pro'
pop:
push:
  push:
    push:
      right: 77pt
      down: 63pt
      fnt: [/usr/local/texlive/2020/texmf-dist/fonts/opentype/public/lm/lmroman10-regular.otf] at 10pt
      set: '>2HHQ'
      right: 3.330002pt
      set: 'q'
      right: -0.830002pt
      set: 'Q`H/5'
    pop:
  pop:
  push:
    right: 232pt
    down: 633pt
    set: 'R'
  pop:
pop:

When compiling with pdflatex, i.e., pdflatex --output-format=dvi test.tex, then a file test.dvi is created without error-messages, too.

But the dviasm-dump via applying dviasm test.dvi -o testpdefdvidump.txt yields testpdfdvidump.txt which looks slightly different:

[preamble]
id: 2
numerator: 25400000
denominator: 473628672
magnification: 1000
comment: ' TeX output 2021.02.08:1918'

[postamble]
maxv: 633pt
maxh: 407pt
maxs: 3
pages: 1

[font definitions]
fntdef: cmr10 at 10pt

[page 1 0 0 0 0 0 0 0 0 0]
push:
  xxx: 'header=l3backend-dvips.pro'
pop:
down: 633pt
push:
  down: -605pt
  down: 575pt
  push:
    down: -540pt
    push:
      right: 77pt
      fnt: cmr10 at 10pt
      set: 'Hello'
      right: 3.333328pt
      set: 'W'
      right: -0.833344pt
      set: 'orld!'
    pop:
  pop:
  down: 30pt
  push:
    right: 232pt
    set: '1'
  pop:
pop:

Differences in fnt:- and fntdef:-directives seem obvious.

What puzzles me is the differences in the set:-directives for the strings:

With the dump from the pdflatex-dvi you have

set: 'Hello'
[...]
set: 'W'
[...]
set: 'orld!'
[...]
set: '1'

With the dump from the lualatex-dvi you have

set: '>2HHQ'
[...]
set: 'q'
[...]
set: 'Q`H/5'
[...]
set: 'R'

and in the LuaLaTeX-dvi-dump (testluadvidump.txt) you need to replace both the fnt:-directives and the set:-directives by those of the pdfLaTeX-dvi-dump before re-creating the .dvi-file via dviasm testluadvidump.txt -o testb.dvi in order to get testb.dvi which is displayed properly.

Seems with test.dvi created by LuaLaTeX the encoding of ⟨string⟩s in set: '⟨string⟩'-directives differs from the encoding of ⟨string⟩s of test.dvi created with pdfLaTeX.

What is the reason for this?

Do the strings reflect the font-encoding while the font-encoding of lmroman10-regular.otf differs from the font-encoding of cmr10?

8
  • 1
    there are development builds of xdvipdfmx with some initial support for luatex dvi Commented Feb 8, 2021 at 19:23
  • @DavidCarlisle So those builds can handle fnt:- and fntdef:-directives denoting .otf-files? Be that as it may. I'm still interested in the reason why with LuaLaTeX-created .dvi-files <string>-values of set: '<string>'-directives seem to be encoded different from those created with pdfLaTeX. Is it really the difference in fonts and font-encoding which causes/requires the differences? Is my guess in this matter correct? Do some other circumstances play a rôle? Commented Feb 8, 2021 at 19:42
  • @UlrichDiez You are assuming dviasm understands LuaTeX DVI, but does it? (I don't know.) Maybe the output is mangled because dviasm doesn't know the format? Commented Feb 8, 2021 at 19:44
  • @PhelypeOleinik Are you indicating that LuaTeX-dvi-format significantly differs from Knuthian TeX's- and pdfTeX's dvi-format? I don't know. But I think: If so, then, like with XeTeX, the format should have a different name (with XeTeX it is called eXtended dvi) and output-files should have a different extension (with XeTeX it is .xdv). Commented Feb 8, 2021 at 19:52
  • 1
    see here about the recent dvipdfmx development: tug.org/pipermail/dvipdfmx/2021-January/000168.html Commented Feb 8, 2021 at 20:04

2 Answers 2

2

LuaTeX manages the encoding for lmroman-regular10 via lmroman-regular10.lua In that file, we can see, for example, that it has

  [72]={
   ["boundingbox"]=12,
   ["index"]=62,
   ["name"]="H",
   ["unicode"]=72,
   ["width"]=750,
  },

which directs the letter H to the index of 62 in the otf font which is ASCII for >. You'll find similar mappings for most characters which indicates that LuaTeX is not using the unicode points for the characters but rather the absolute index of the character in the otf.

There's also a .luc file which I'm guessing is a binary-compiled version of the .lua file.

0
0

I encountered this issue with fntdef and set/put commands while developing dvi-decode for LuaTeX.

Here is an extract from the source code comments discussing what I found:

"Font names included in DVI files generated by dvilualatex can be either proper names or file names depending on the fontspec commands used to select them. Since dvi-decode does not have access to the luatex font loader, it can only accept a DVI file that uses file names in the font name strings.

The best was to ensure this is the case is to explicitly define your fonts in your LaTeX source using the fontspec commands \setmainfont, setmathfont etc, using filename form, for all fonts used in the document.

The font name strings included in DVI files generated by dvilualatex also append to the end of the font name extra text that encodes font features. We separate this string from the font name and return it in the fontFeatures field of the output font object.

Additionally, the font features mode and shaper affect the meaning of the parameters of the set and put commands generated by dvilualatex. A parameter could mean a Unicode code, or it could mean a glyph index, or it may mean either depending on whether the value falls within a particular range.

As far a I can determine these variations in parameter encodings are not fully documented, and I was not able to discover the various encoding schemes from the LuaTeX source due to it's great many levels of abstraction.

Therefore, rather than try to code for all possible variations of the mode and shaper options, I have chosen harf and ot as the mode and shaper respctively that dvi-decode will support. These features can be specified by including Renderer=OpenType in the font definitions of the LaTeX source. If these features are not found in the FontFeatures string of any font, dvi-decode will abort processing."

I ended up having to read the .lua files in addition to the font files to find the correct glyph indexes.

5
  • That sounds like you are reading DVI files from old versions of luaotfload. Current versions generate much more normalized files where fontnames are always paths (independent of the fontspec argument used) and parameter of the set and put are always GIDs (independent of the mode). Only a small number of features wil ever be present in this names, not including mode. If you get other files, you either explicitly disabled the new DVI handling, have an outdated luaotfload version, or encountered a bug. Commented Oct 30, 2022 at 22:07
  • My dvilualatex logs show:luaotfload | init : Context OpenType loader version 3.116. Whay is the latest version? I was definately seeing Unicode values, not GID's in some set and put commands.
    – matjpse
    Commented Oct 30, 2022 at 22:38
  • The relevant version is the luaotfload version and not the Context loader version, but but if you have a Context loader version of 3.116 you probably have roughly luaotfload 3.19. The current version is luaotfload 3.23. It might be that you encountered a recently fixed bug which broke the DVI handling for characters which are only used in display math. Commented Oct 30, 2022 at 23:20
  • Thanks Marcel. I see now I have v3.18 and that the change to use GID's was made in v3.15. I will do some testing with the latest version to see if there is still an issue. It would be good to not have to rely on reading the .lua files.
    – matjpse
    Commented Oct 30, 2022 at 23:52
  • Based on testing with a more recent luaotfload package, I have removed the dependency on Lua font files from dvi-decode.
    – matjpse
    Commented Nov 17, 2022 at 0:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .