Frank,
> On Sep 13, 2023, at 16:33, Frank H. Ellenberger
> wrote:
>
> Hi Geert,
>
> why is it using font-family:Bitstream Vera Sans? Some non-latin glyphs are
> not supported by this fonts. Any suggestions for a font with full utf-8
> support?
>
It's irrelevant. It's artwork and there's no reason at all that every
translation of the Guide has to use the same font for that image any more than
they do for the text. Translators can change it if it doesn't work in their
language or if they like something else, as Xu did for Chinese.
> When I open it with Inkscape 1.3 it wants to change the resolution. Should we?
Change what resolution? The inkscape export dpi, currently 90? It probably
doesn't matter, inkscape isn't part of our toolchain.
>
> For html and the website
> [https://www.gnucash.org/images/features/basics_AccountRelationships.*.png]
> we convert it to a png file and use that. AFAIK today docbook and html can
> handle svg files. Should we drop the png file and use also there the svg
> directly?
That's a bit of misdirection. Docbook is an XML markup schema. It doesn't
process anything, xslt stylesheets convert its markup to layout markups, in our
case HTML/CHM, PDF, and ePUB/MOBI. The SVG would be embedded directly into
those formatted documents, and it's up to the program presenting the document
to the user to render the the SVG.
You're right that HTML browsers can do that. So can ebook readers supporting
ePUB 3.0 or later. Older Kindles, the ones that use MOBI instead of ePUB,
cannot, nor can Microsoft Help (CHM). SVG is not part of PDF so we'd have to
add Apache Batik to the workflow to convert the SVG to PDF and integrate that
with Apache FOP to produce the final PDF.
Calibre, the program we use to create MOBI documents from ePUB, converts SVG
images to png when making a MOBI so that's not a problem.
That leaves CHM: We can (and should!) drop CHM support. Microsoft stopped using
it for their own documentation somewhere around 2005 and sooner or later will
get rid of Microsoft Help. Or maybe they already have and unlike WordPad nobody
noticed.
If your goal is to remove the duplication of having both the png and svg
artwork in the repo an alternative would be to add ImageMagick to the pipeline
and generate the pngs during the documentation build. But the real point of SVG
is to delay setting the resolution until display time so embedding it in HTML
and ePUB and converting it to PDF (which also sets resolution at display time)
would produce better-quality graphics in those media.
Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
