View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001013||context||bug report||public||2019-09-08 09:17||2019-09-11 11:40|
|Target Version||Fixed in Version|
|Summary||0001013: Color SVG in OpenType font does not appear in PDF|
Color SVG in OpenType font format seems supported.
After downloading Abelone font from
to current directory and use "context" to the below file, PDF does not contain letters in Abelone font.
\colorsvgfont ABCD efgh
A part of the log shows
fonts > svg conversion > executing runner 'otfsvg': inkscape --shell > temp-otf-svg-shape.log
fonts > svg conversion > processing 96 svg containers
fonts > svg conversion > processing 96 pdf results
fonts > svg conversion > svg conversion time 2.197 seconds
So the SVG-to-PDF conversion by inkscape was executed by context, but glyphs did not appear in PDF.
The related generated files are attached below. ConTeXt version is
$ context --version
mtx-context | ConTeXt Process Management 1.02
mtx-context | main context file: /usr/local/texlive/2019/texmf-dist/tex/context/base/mkiv/context.mkiv
mtx-context | current version: 2019.03.21 21:39
|Tags||No tags attached.|
temp-otf-svg-shape.log (183 bytes)
colorsvg.tuc (5,360 bytes)
colorsvg.pdf (10,062 bytes)
colorsvg.log (11,710 bytes)
colorsvg.tex (118 bytes)
||the font is not ok, the shapes are out of the viewbox so nothing ends up in the pdf blobs|
Hans, thank you for your attention and investigation. I am sorry for bothering you by a bogus font.
I tested two other fonts
Playbox from https://www.fontself.com/colorfontweek/2018 (middle of the page) and
Gilbert from https://github.com/Fontself/TypeWithPride/releases/download/1.005/Gilbert_1.005_alpha.zip
in place of the Abelone font. The none of the above two fonts generated reasonable results. Should I consider that Playbox and Gilbert are also bogus fonts...?
Related source files and generated files are attached below. I really hope NOT bothering you by bogus fonts.
If all the fonts I tested so far are bogus, I would appreciate it if you could tell a Color SVG-in-OpenType font for testing ConTeXt.
colorsvg3.tuc (5,361 bytes)
colorsvg3.pdf (11,815 bytes)
colorsvg3.log (10,231 bytes)
colorsvg3.tex (135 bytes)
colorsvg2.tuc (5,361 bytes)
colorsvg2.pdf (12,851 bytes)
colorsvg2.log (7,405 bytes)
colorsvg2.tex (118 bytes)
the problem with these fonts is that they specify a viewbox of 0 1000 0 1000 while their shapes are someplace else so it's sloppy svg (maybe the same application is used to produce them) ... now, of course one can deal with that (thereby turning a bug into a feature as usual) but ...
anyway, what you can try is this: on font-ocl.lua replace
then remake the context format and wipe the bad behaving fonts from the texmf-cache subpaths (or just wipe the cache)
i then see Abelone-FREE.otf show up as well as Gilbert-ColorBoldPreview5 although the later has issues (for instance a 'g' has bad dimensions)
maybe there is a better inkscape option
i can try to tweak the boundingbox in the svg and see if that improves matters
oeps.pdf (242,003 bytes)
this kind of works ... but these fonts seem to have pretty bad kerning so one needs additional intercharacter kerns
oeps-2.pdf (260,594 bytes)
Thank you very much! I use Linux and making file /usr/local/texlive/2019/bin/x86_64-linux/inkscape as
exec /usr/bin/inkscape --export-area-drawing "$@"
forced glyphs to appear in PDFs in all the fonts I tested.
As another example, I tested Twitter Emoji font in SVG-OT format from
Without --export-area-drawing no glyph appeared and with it a glyph appeared.
The Twitter SVG-OT font seems also having improper bounding boxes.
> the problem with these fonts is that they specify a viewbox of 0 1000 0 1000 while their shapes are someplace else so it's sloppy svg (maybe the same application is used to produce them) ... now, of course one can deal with that (thereby turning a bug into a feature as usual) but ...
The problem isn't with the fonts, the fonts just do what the specification mandates. The ViewBox isn't used as a bounding box of sorts, it only gives the origin and a scaling factor: (from https://docs.microsoft.com/en-us/typography/opentype/spec/svg)
> The default SVG coordinate system is vertically mirrored in comparison to the TrueType/CFF design grid: the positive y-axis points downward, rather than usual convention for OpenType of the positive y-axis pointing upward. In other respects, the default coordinate system of an SVG document corresponds to the TrueType/CFF design grid: the default units for the SVG document are equivalent to font design units; the SVG origin (0,0) is aligned with the origin in the TrueType/CFF design grid; and y = 0 is the default horizontal baseline used for text layout.
> The size of the initial viewport for the SVG document is the em square: height and width both equal to head.unitsPerEm. If a viewBox attribute is specified on the <svg> element with width or height values different from the unitsPerEm value, this will have the effect of a scale transformation on the SVG “user” coordinate system. Similarly, if height or width attributes are specified on the <svg> element, this will also have the effect of a scale transformation on the coordinate system.
> Although the initial viewport size is the em square, the viewport must not be clipped. The <svg> element is assumed to have a clip property value of auto, and an overflow property value of visible. A font should not specify clip or overflow properties on the <svg> element. If clip or overflow properties are specified on the <svg> element with any other values, they must be ignored.
> Note: Because SVG uses a y-down coordinate system, then by default, glyphs will often be drawn in the +x -y quadrant of the SVG coordinate system. (See Example 2.) In many other environments, however, graphic elements may need to be in the +x +y quadrant to be visible. Font development tools should provide an appropriate transfer between a design environment and the representation within the font’s SVG table. In Example 3, a viewBox attribute is used to shift the viewport up. In Example 4, a translate transform is used on container elements to shift the graphic elements that comprise the glyph descriptions.
|2019-09-08 09:17||emojifreak||New Issue|
|2019-09-08 09:17||emojifreak||File Added: temp-otf-svg-shape.log|
|2019-09-08 09:17||emojifreak||File Added: colorsvg.tuc|
|2019-09-08 09:17||emojifreak||File Added: colorsvg.pdf|
|2019-09-08 09:17||emojifreak||File Added: colorsvg.log|
|2019-09-08 09:17||emojifreak||File Added: colorsvg.tex|
|2019-09-09 13:43||Hans Hagen||Note Added: 0001717|
|2019-09-10 00:47||emojifreak||File Added: colorsvg3.tuc|
|2019-09-10 00:47||emojifreak||File Added: colorsvg3.pdf|
|2019-09-10 00:47||emojifreak||File Added: colorsvg3.log|
|2019-09-10 00:47||emojifreak||File Added: colorsvg3.tex|
|2019-09-10 00:47||emojifreak||File Added: colorsvg2.tuc|
|2019-09-10 00:47||emojifreak||File Added: colorsvg2.pdf|
|2019-09-10 00:47||emojifreak||File Added: colorsvg2.log|
|2019-09-10 00:47||emojifreak||File Added: colorsvg2.tex|
|2019-09-10 00:47||emojifreak||Note Added: 0001718|
|2019-09-10 10:00||Hans Hagen||File Added: oeps.pdf|
|2019-09-10 10:00||Hans Hagen||Note Added: 0001719|
|2019-09-10 12:46||Hans Hagen||File Added: oeps-2.pdf|
|2019-09-10 12:46||Hans Hagen||Note Added: 0001720|
|2019-09-10 19:33||emojifreak||Note Added: 0001721|
|2019-09-11 11:40||mkrueger||Note Added: 0001722|