mgieseki / dvisvgm

A fast DVI, EPS, and PDF to SVG converter
https://dvisvgm.de
GNU General Public License v3.0
310 stars 34 forks source link

Virtual font fallback to OFM for pTeX #241

Closed t-tk closed 1 year ago

t-tk commented 1 year ago

Hallo, Thank you for developing dvisvgm.

I have proposed an enhancement of feature of virtual font which designates CJK TFM/OFMs. The previous one is discussed at Virtual font fallback to Japanese tfm 和文vf の fallback を dviware で

I have written some tests to show my expectation: https://github.com/t-tk/texlive-source/commit/3e827146f98f7be2a41149f6a5d74084ff43dbf4

It does not work and fails by segmentation fault even if the test is in the conventional fallback feature.

I hope the features will be supported by future dvisvgm. Thanks.


(Extended feature, 2023-04-29)

The rule for virtual fonts (VF) fallback is extended: If a VF has no entry of a codepoint and the first MAPFONT designates an OFM for (u)pTeX, then we designate the glyph (usually with a fullwidth metric) of the same codepoint with the same metrics of the codepoint in the OFM.

mgieseki commented 1 year ago

Thank you for the information. Could you please provide all files required to perform the tests independently of the TeX Live sources? Currently, I can't reproduce the segmentation faults. dvisvgm just prints several warnings, e.g.

*** dvisvgm: test for upjf_full

pre-processing DVI file (format version 3)
WARNING: font file 'upjv-r.mf' not found
WARNING: font file 'upjv-g.mf' not found
WARNING: font file 'upjf-r.mf' not found
WARNING: font file 'upjf-g.mf' not found
WARNING: font file 'cmr10.pfb' not found
processing page 1
  graphic size: 219.455205pt x 212.999624pt (77.129683mm x 74.860806mm)
  WARNING: can't embed font 'upjv-g'
  WARNING: can't embed font 'cmr10'
  WARNING: can't embed font 'upjf-r'
  WARNING: can't embed font 'upjv-r'
  WARNING: can't embed font 'upjf-g'
  output written to upjf_full.svg
1 of 1 page converted in 0.523378 seconds

As a first step it would help to have all data available to test a single case that leads to a segfault.

t-tk commented 1 year ago

If the following lines are comment out by #, the segfault will be reproduced. https://github.com/t-tk/texlive-source/blob/3e827146f98f7be2a41149f6a5d74084ff43dbf4/texk/dvisvgm/tests/dvisvgm-uptex.test#L36-L39

mgieseki commented 1 year ago

Ok, thanks for the hint. I've fixed the cause of the segfaults.

mgieseki commented 1 year ago

The latest changes add OFM support and the corresponding VF fallback mechanism.

t-tk commented 1 year ago

Thank you for the update. I imported the sources and tested. The segfault was fixed, but I could not get the same result between w/ and w/o fallback.

https://github.com/t-tk/texlive-source/commit/aea985637d3444f28150b7995a5c580fbcaf2140

mgieseki commented 1 year ago

Do you get any warning messages from dvisvgm? For my tests I needed to adapt your upjf.map because it doesn't specify font files for the fonts listed there. Thus, I got the warnings shown above.

I use these entries taken from texk/dvipdfm-x/tests/upjf.map and get correct conversion results with them:

upjf-r   UniJIS-UTF16-H  HaranoAjiMincho-Regular.otf
upjf-g   UniJIS-UTF16-H  HaranoAjiGothic-Regular.otf
upjv-r   UniJIS-UTF16-V  HaranoAjiMincho-Regular.otf
upjv-g   UniJIS-UTF16-V  HaranoAjiGothic-Regular.otf
t-tk commented 1 year ago

Thank you for your comment. I got intended results by using the following entries in the map file upjf.map.

https://github.com/t-tk/texlive-source/commit/27ac1f774b332077b7de2fb306aacd805e2139c1


upjf-r   unicode  HaranoAjiMincho-Regular.otf
upjf-g   unicode  HaranoAjiGothic-Regular.otf
upjv-r   unicode  HaranoAjiMincho-Regular.otf
upjv-g   unicode  HaranoAjiGothic-Regular.otf
mgieseki commented 1 year ago

Great, thanks for the confirmation. Since the additions seem to work as expected, I'm closing the ticket for now. Feel free to open it again if you still find any issues.

t-tk commented 1 year ago

Thank you for your support.