Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Color SVG in OpenType font always rendered in B&W #96

Open
emojifreak opened this issue Sep 8, 2019 · 11 comments
Open

Color SVG in OpenType font always rendered in B&W #96

emojifreak opened this issue Sep 8, 2019 · 11 comments

Comments

@emojifreak
Copy link

@emojifreak emojifreak commented Sep 8, 2019

Background: ConTeXt officially supports Color SVG in OpenType font as stated in
https://meeting.contextgarden.net/2017/talks/2017-09-12-hans-color-fonts/picture-fonts.pdf
but it seems broken in the sense that no glyph appears in PDF as reported at
http://tracker.luatex.org/view.php?id=1013

After downloading Abelone color font from
https://www.fontself.com/colorfontweek/2018#abelone
to current directory and use lualatex to the following file

{{{
\documentclass{minimal}
\font\svgcolorfont={file:./Abelone-FREE.otf:+svg}
\begin{document}
\noindent
\svgcolorfont ABCDEF abcdef
\end{document}
}}}

  1. PDF has the glyph in black and white and is exactly the same as PDF without +svg. So the fallback B&W glyph in the font file is used for PDF generation.
  2. file inkscape --shell > temp-otf-svg-shape.log is generated.
  3. If +svg is removed from the above TeX source, then file inkscape --shell > temp-otf-svg-shape.log is not generated.

It seems that LuaLaTeX converts SVG in the font file to PDF, tries to embed converted PDF
and fails. I have made sure that my installation of inkscape can convert SVG to PDF by inkscape file.svg -A file.pdf.

Conclusion:

  • If LuaLaTeX+luaotfload do not support SVG-in-OpenType then there is no point to convert SVG in a font file to PDF and hopefully it can give an error message to +svg
  • If LuaLaTeX+luaotfload do support SVG-in-OpenType then the functionality seems broken.
@emojifreak

This comment has been minimized.

Copy link
Author

@emojifreak emojifreak commented Sep 10, 2019

The similar issue in ConTeXt can be worked around by addition of --export-area-drawing to execution of inkscape as noted at
http://tracker.luatex.org/view.php?id=1013#c1719

But the above workaround does not work for this issue, so this issue seems independent of the similar issue in ConTeXt.

@zauguin

This comment has been minimized.

Copy link
Member

@zauguin zauguin commented Sep 11, 2019

@emojifreak The created file is caused by a typo in ConTeXt, so we will have to wait for the ConTeXt team to fix it. Even then, the conversion will almost always fail: By default, LuaLaTeX does not allow unrestricted shell-escape, so the code is not allowsed to call arbitrary programs like inkscape for security reasons. Therefore, and also because I think that SVG-in-OpenType is a bad idea in the first place, I would tend to say that it is not supported. Still I am reluctant with giving an outright error because I would like to allow users to experiment with this, given that the fontloader implements most parts anyway. So maybe we can add a warning...

Off topic, but given that we are talking about warnings anyway: Have you noticed that your examples gives a warning about paths in file lookups?

luaotfload | load : warning: path in file: lookups is deprecated;
luaotfload | load : use bracket syntax instead!

Basicalls file:./Abelone-FREE.otf:+svg is deprecated, if you want to pass a path use [./Abelone-FREE.otf]:+svg instead or, if the font is in the current directory (or one of your system font directories) anyway, just omit the path: file:Abelone-FREE.otf:+svg

@zauguin

This comment has been minimized.

Copy link
Member

@zauguin zauguin commented Sep 11, 2019

On dev-context Hans is taking care of the upstream issue.

@emojifreak

This comment has been minimized.

Copy link
Author

@emojifreak emojifreak commented Sep 11, 2019

@zauguin Thank you very much for the detailed comment!

Therefore, and also because I think that SVG-in-OpenType is a bad idea in the first place, I would tend to say that it is not supported. Still I am reluctant with giving an outright error because I would like to allow users to experiment with this, given that the fontloader implements most parts anyway. So maybe we can add a warning...

I understand the development policy. I have absolutely no objection about it.

Off topic, but given that we are talking about warnings anyway: Have you noticed that your examples gives a warning about paths in file lookups?

Thanks again. I will use a correct (up-to-date) syntax in the next time.

On dev-context Hans is taking care of the upstream issue.

I saw (part of ?) your comment as http://tracker.luatex.org/view.php?id=1013#c1722

@emojifreak

This comment has been minimized.

Copy link
Author

@emojifreak emojifreak commented Nov 12, 2019

@zauguin Thank you for your work. This issue is almost fixed as below. When I use lualatex + luaotfload 3.1 on the below file with lualatex --shell-escape

\documentclass{minimal}
\font\svgcolorfont={[./Abelone-FREE.otf]:+svg;}
\begin{document}
\noindent
\svgcolorfont \LaTeX
\end{document}

lualatex gives the error texmf-dist/tex/luatex/luaotfload/fontloader-2019-10-29.lua:27743: attempt to call a nil value (field 'getindices').
But the above error can be easily fixed by one line modification below:

diff -u texlive/2019/texmf-dist/tex/luatex/luaotfload/fontloader-2019-10-29.lua-org texlive/2019/texmf-dist/tex/luatex/luaotfload/fontloader-2019-10-29.lua
--- texlive/2019/texmf-dist/tex/luatex/luaotfload/fontloader-2019-10-29.lua-org	2019-11-06 06:35:11.000000000 +0900
+++ texlive/2019/texmf-dist/tex/luatex/luaotfload/fontloader-2019-10-29.lua	2019-11-12 12:04:47.276555233 +0900
@@ -27740,7 +27740,6 @@
   local pdfshapes={}
   local inkscape=runner()
   if inkscape then
-   local indices=fonts.getindices(tfmdata)
    local descriptions=tfmdata.descriptions
    local nofshapes=#svgshapes
    local f_svgfile=formatters["temp-otf-svg-shape-%i.svg"]

and with the above correction lualatex --shell-escape produced the attached PDF svg1.pdf, which seems the desired result.
svg1.pdf

@u-fischer

This comment has been minimized.

Copy link

@u-fischer u-fischer commented Nov 12, 2019

This looks like an upstream error in the generic fontloader. Please report it on the context mailing. When they adapt the fontloader we can import it,

@emojifreak

This comment has been minimized.

Copy link
Author

@emojifreak emojifreak commented Nov 12, 2019

@u-fischer Thanks for your quick response.

This looks like an upstream error in the generic fontloader. Please report it on the context mailing. When they adapt the fontloader we can import it,

The error in luaotfload is caused by the absense of definition of the function getindices.
In ConTeXt, the function getindices is defined in
https://source.contextgarden.net/tex/context/base/mkiv/font-aux.lua
Then getindices is used in ConTeXt SVG-to-PDF conversion in
https://source.contextgarden.net/tex/context/base/mkiv/font-ocl.lua

There seems no problem in the upstream ConTeXt.
The problem SEEMS that luaotfload does not incorporate font-aux.lua from ConTeXt.

If there is a problem in ConTeXt, please tell me it. I see nothing to be reported to the ConTeXt team.

@u-fischer

This comment has been minimized.

Copy link

@u-fischer u-fischer commented Nov 12, 2019

yes it is a context problem, the fontloader is (more or less) a copy of the generic font loader provided by context (luatex-fonts-merged.lua in tex/generic/context/luatex) and as you remarked it refers to an undefined function.

@emojifreak

This comment has been minimized.

Copy link
Author

@emojifreak emojifreak commented Nov 12, 2019

yes it is a context problem

Sorry I cannot see your point. The function getindices seems defined at
https://source.contextgarden.net/tex/context/base/mkiv/font-aux.lua
If there is a problem in ConTeXt, I cannot see how to expose that problem in ConTeXt...

the fontloader is (more or less) a copy of the generic font loader provided by context (luatex-fonts-merged.lua in tex/generic/context/luatex)

The mkimport script
https://github.com/latex3/luaotfload/blob/master/scripts/mkimport
does not contain font-aux.lua. I suspect that it is a part of the problem. Could you confirm that absense of font-aux.lua in mkimport is correct?

Actually, Section 9.2 of luaotfload-latex.pdf says:

Throughthe script mkimport a ConTEXt library is invoked to create the luaotfload fontloader as a merged (amalgamated) source file. This file constitutes the “default fontloader” and is part of the luaotfload package as fontloader-YY-MM-DD.lua, where the uppercase letters are placeholders for the build date

I believe that if the mkimport script puts font-aux.lua into fontloader-YY-MM-DD.lua then the problem is fixed, and that a correct fix is to add font-aux.lua to mkimport script living in luaotfload github.

@u-fischer

This comment has been minimized.

Copy link

@u-fischer u-fischer commented Nov 12, 2019

We don't and can't import all lua-files from context - some of them are incompatible. We only import the files which are listed in luatex-fonts.lua. So please write to the list and say that the generic fontloader is using an undefined function. Hans will manage, and if he doesn't I can still interfere.

@emojifreak

This comment has been minimized.

Copy link
Author

@emojifreak emojifreak commented Nov 12, 2019

@u-fischer Thank you for your kind explanation and I am sorry for my slow understanding. I reported it at http://tracker.luatex.org/view.php?id=1013#c1724

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.