Hacker News new | past | comments | ask | show | jobs | submit login

Yes that's right. Consider a TeX file test.tex containing

    $\int$ \nopagenumbers \bye
or if you prefer LaTeX, containing

    \documentclass{article}\pagestyle{empty}\begin{document}$\int$\end{document}
If you run "tex" or "latex" on this, it will generate a test.dvi. You can look at a human-readable representation of the DVI file with dvitype or dviasm — what it says is to move to a particular position, and set the character at position 82 ('R') from the font "cmex10 at 10pt".

Then you can run either dvipng or dvisvgm (or dvipdfmx, or…) on this, which will take this instruction, read in the font (for example, it may load file /usr/local/texlive/2019/texmf-dist/fonts/type1/public/amsfonts/cm/cmex10.pfb) and replace it with the pixels (at a given resolution) or shape from the font. In case of SVG, it may pick the actual description (as a path) from the (vector) font:

    <glyph unicode='' horiz-adv-x='472' vert-adv-y='472' glyph-name='integraltext' d='M272 -880C259 -1044 223 -1089 166 -1089C153 -1089 123 -1086 102 -1068C131 -1064 139 -1041 139 -1027C139 -998 117 -985 98 -985C78 -985 56 -998 56 -1028C56 -1076 106 -1111 166 -1111C261 -1111 309 -1024 331 -934C344 -882 380 -591 388 -480L407 -231C421 -47 455 -22 500 -22C510 -22 541 -24 563 -43C534 -47 526 -70 526 -84C526 -113 548 -126 567 -126C587 -126 609 -113 609 -83C609 -35 559 0 499 0C404 0 365 -97 348 -173C336 -228 300 -510 291 -631L272 -880Z'/>
----

You may be interested to know where the description in the font came from. The short answer is "the font designer" (of whatever font is being used). In this case, cmex10 is the "math extension" font from the Computer Modern family designed by Donald Knuth (the author of TeX and METAFONT). He described the shape in METAFONT, etc. All that's another story :)




Thank you, very interesting and helpful. (I ran dvitype on that as you suggested.)

I think I'm just going to describe what I'm doing in case you have any more helpful words of advice or thoughts! Obviously no worries if not.

I'm working on a project that involves generating images from LaTeX math fragments and displaying them in a text editor buffer inline with the text, to create an environment for editing LaTeX math without needing to constantly regenerate the PDF. So similar to what also exists in various places, e.g. preview-latex and org-mode in Emacs.

In one sentence: I am struggling to produce non-fuzzy images when using dvipng or imagemagick to produce a PNG.

I am at the stage where I am trying to identify the best image-generation workflows to support. Users might have conventional screens, or high res ("4k?") screens, or high res Apple Retina screens. For example, Emacs org-mode offers the following 3 flows:

* dvisvgm - LaTeX DVI output is converted to SVG and Emacs displays the SVG.

* imagemagick - LaTeX PDF output is converted to PNG by imagemagick and Emacs displays the PNG.

* dvipng - LaTeX DVI output is converted to PNG and Emacs displays the PNG.

I personally own a Macbook Pro with a Retina screen and what I have observed is:

Iff your text editor is built with special support for Retina screens:

1. Beautiful crisp results can be obtained via dvisvgm.

2. It is also possible to produce a high resolution PNG and then resize it down in the editor so that it retains its crisp appearance at small size.

However, using dvipng (latex -> dvi -> png) or imagemagick (latex -> pdf -> png) I have not yet managed to obtain any crisp images of math fragments when they are at the size of a conventional line of text on the screen. That's on a Retina screen; I'm also planning to test against a conventional monitor via a raspberry pi.

I believe that dvipng does not include a "pHYs" chunk in the PNG data, and that this may be one reason that I am struggling to create small PNGs with high pixel density.


Ah rasterization is another rabbit hole that I don't know much about and can't say anything without trial-and-error experimentation on the specific device :-) But first I'd recommend checking whether the image is being displayed at its natural size, pixel-for-pixel (or conversely that it is being generated to have the number of pixels at which it is going to be displayed -- both imagemagick and dvipng take a dpi option). See also some approaches at https://tex.stackexchange.com/questions/44486/pixel-perfect-...


Thanks! (And crikey, that is quite a post!)




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: