Re: [Plplot-devel] Fonts and svgqt device

On 2009-05-13 14:35+0100 Alban Rochel wrote:
> Hello all,
>
> Working on the QSAS version of the Qt PLplot driver, I've added the
> possibility to convert fonts to vector paths for SVG export. This solves
> the font rendering issues in SVG (wrong sizes, wrong offsets, depending
> on the editor used), BUT makes the text non-editable (and the files
> slightly bigger).
>
> I may add this feature to a future update of the Qt drivers. Is the
> PLplot community interested in that? As an option? As the default option?
Yes please (!) as the default option for svgqt (and as the non-default
option for all other qt devices if possible).
As you say it works around the current text positioning bugs for many of the
SVG viewers/editors. But another benefit is it works around a fundamental
font-handling bug I have reported to Qt for their SVG backend. The SVG
standard allows font hints (I think they call it generic font families), but
instead of using that for our case where the font family is a null string,
and our Qt font hints are supposed to be followed because of that, Qt simply
ignores our hints in this case and outputs SVG files with a null string font
family. Thus, currently, SVG viewers/editors dealing with out svgqt files
have to use their fallback fonts (usually sans) regardless of what generic
font hint (sans, sans-serif, monotype, etc.) PLplot has specified which
makes the results legible but far from satisfactory.
Note that libcairo handles all their fonts as embedded (i.e., rendered as
vector paths within the file) so that is what we get for all the cairo
devices. So if it is possible, you may want to supply an embedded font
option for all Qt devices. But it should probably be non-default for
everything but svgqt since it might be a useful option to have in certain
cases (sending a plot to someone who does not have your rich family of
fonts), but the case for this feature for other Qt devices is not as
compelling as for the svgqt case.
In sum, using embedded vector path fonts would be most welcome as the
default option for svgqt. At the point when the positioning bugs in svg
viewers/editors and the bug in handling font hints for the SVG backend of Qt
are solved we can always change the default back to how fonts are currently
handled in svgqt since it does make the files smaller and allows you to edit
the text in them. Using embedded vector path fonts for all other Qt devices
would also be a useful non-default option.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________

Thread view

Hello all,
Working on the QSAS version of the Qt PLplot driver, I've added the
possibility to convert fonts to vector paths for SVG export. This solves
the font rendering issues in SVG (wrong sizes, wrong offsets, depending
on the editor used), BUT makes the text non-editable (and the files
slightly bigger).
I may add this feature to a future update of the Qt drivers. Is the
PLplot community interested in that? As an option? As the default option?
Cheers,
Alban

On 2009-05-13 14:35+0100 Alban Rochel wrote:
> Hello all,
>
> Working on the QSAS version of the Qt PLplot driver, I've added the
> possibility to convert fonts to vector paths for SVG export. This solves
> the font rendering issues in SVG (wrong sizes, wrong offsets, depending
> on the editor used), BUT makes the text non-editable (and the files
> slightly bigger).
>
> I may add this feature to a future update of the Qt drivers. Is the
> PLplot community interested in that? As an option? As the default option?
Yes please (!) as the default option for svgqt (and as the non-default
option for all other qt devices if possible).
As you say it works around the current text positioning bugs for many of the
SVG viewers/editors. But another benefit is it works around a fundamental
font-handling bug I have reported to Qt for their SVG backend. The SVG
standard allows font hints (I think they call it generic font families), but
instead of using that for our case where the font family is a null string,
and our Qt font hints are supposed to be followed because of that, Qt simply
ignores our hints in this case and outputs SVG files with a null string font
family. Thus, currently, SVG viewers/editors dealing with out svgqt files
have to use their fallback fonts (usually sans) regardless of what generic
font hint (sans, sans-serif, monotype, etc.) PLplot has specified which
makes the results legible but far from satisfactory.
Note that libcairo handles all their fonts as embedded (i.e., rendered as
vector paths within the file) so that is what we get for all the cairo
devices. So if it is possible, you may want to supply an embedded font
option for all Qt devices. But it should probably be non-default for
everything but svgqt since it might be a useful option to have in certain
cases (sending a plot to someone who does not have your rich family of
fonts), but the case for this feature for other Qt devices is not as
compelling as for the svgqt case.
In sum, using embedded vector path fonts would be most welcome as the
default option for svgqt. At the point when the positioning bugs in svg
viewers/editors and the bug in handling font hints for the SVG backend of Qt
are solved we can always change the default back to how fonts are currently
handled in svgqt since it does make the files smaller and allows you to edit
the text in them. Using embedded vector path fonts for all other Qt devices
would also be a useful non-default option.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________