See http://lists.cairographics.org/archives/cairo/2010-November/021071.html

And http://lists.cairographics.org/archives/cairo/2011-February/021777.html

Created attachment 48224 [details] [review]
patch from Jonathan Marchand

The patch is wrong as it loses the glyph information!

Created attachment 51255 [details] [review]
show_text_glyphs support

This patch for show_text_glyphs support.
Please call cairo_svg_set_support_text_glyphs(svg_surface,TRUE)

Comment on attachment 51255 [details] [review]
show_text_glyphs support

In addition, this patch is more efficient to specify fill and stroke style.

Hi Tatsuhiko,

I've just had a quick look at your patch and it looks exciting. I will try to review it this week-end.

I have a first remark: it would be better to submit smaller patches by not mixing unrelated work. It's quite unfortunate to have the _round modification here. By the way, could you explain what's for ?

Thanks a lot for your work.

Created attachment 51257 [details] [review]
Smaller patch

Most fonts would have been made ​​by 1000x1000 mesh. So we reduce the font data to be possible.

Review of attachment 51257 [details] [review]:

1. I'm sure we have UTF-8 functions you can reuse.  You seem to have copied from glib, which has licensing problems too.

2. Most fonts actually have a upem of 2048.  TrueType fonts that is.  Just don't mess with the precision for now.  The big win is to store them in upem units as ints.  But that should be a followup patch.

::: src/cairo-svg.h
@@ +52,3 @@
 } cairo_svg_version_t;
 
+typedef cairo_status_t (*cairo_write_image_func_t) (void		  *closure,

What's this?!

@@ +79,3 @@
 
+cairo_public void
+cairo_svg_set_support_text_glyphs (cairo_surface_t 		*surface,

Wrong.  No need to have this.  User can decide whether to call cairo_show_glyphs() or cairo_show_text_glyphs() for themselves.

Created attachment 51287 [details] [review]
Changed unit-per-em to 2048.

+typedef cairo_status_t (*cairo_write_image_func_t) (void          *closure,
Sorry, this is needless. Other changes were added by mistake.
I agree about cairo_svg_set_support_text_glyphs.

I changed upem to 2048.
Is it can get upem from cairo scaled font?

I tried this patch with three different SVG viewers and got different results in all three.

firefox - The text is displayed but in a different (fallback?) font.

inkscape - same as firefox but with with a different fallback font.

rsvg-view - the font looks to be correct but it is hard to tell because most of the text is off the page.

(In reply to comment #11)

> I changed upem to 2048.

Did you consider emitting outlines in font-space, as integers?

> Is it can get upem from cairo scaled font?

No, but would be trivial to add that internally.

> Did you consider emitting outlines in font-space, as integers?
Because I want to cut down the size of the data as possible.
But this is not absolutely necessary.


UTF-8 functions are copied from cairo-unicode.c.

(In reply to comment #14)
> > Did you consider emitting outlines in font-space, as integers?
> Because I want to cut down the size of the data as possible.
> But this is not absolutely necessary.

You're converting to integer, rounding, converting back to some other space.  I was saying: can't you keep the outline in integer and apply the transformation in some other place?


> UTF-8 functions are copied from cairo-unicode.c.

Why copy?

Created attachment 51402 [details] [review]
Apply some fix

Now output numbers without rounding.

> Why copy?
I created a function.

Additionally, fixed a bug about white space.

Is this patch finished?

Having text a text would really make touching up plots for print much easier.

> +cairo_public void
> +cairo_svg_set_support_text_glyphs (cairo_surface_t         *surface,
> 
> Wrong.  No need to have this.  User can decide whether to call
> cairo_show_glyphs() or cairo_show_text_glyphs() for themselves.

What if the user doesn't call cairo_show directly but use pango_cairo_show_layout ? I think the method used for showing glyphs (<text> or <glyph>) should be configurable. Text support in the different open source svg renderers is quite bad, and the <glyph> method is a good way to ensure a good rendering.

Are there any updates to this?

It’s appreciated that the goal for Cairo is to achieve the same output across platform × machine × backend.

But in SVG particularly the advantage is editability among others. In some situations it doesn’t overly matter if the text is pixel perfect, it’s more important to have text-as-text.

I stumbled on this short comming, because `pybootchartgui` from bootchart2 [1] creates files which are 8 MB big and SVG file cannot be searched for certain words.

It would be awesome, if the developers could give an update.


[1] https://github.com/mmeeks/bootchart/tree/master/pybootchartgui

I would argue that having <text> tags in the SVG output is more important than reproducing the precise glyph positions. From an end-user-perspective the current behaviour classifies as "bug" and not just as "minor". 

As an application developer I chose Cairo not least because it promised to make it trivial to produce PDF and SVG exports of the graphics my software renders on screen. The typical use case for PDF is printing. Here, exact reproduction of the rendered output is indeed critical. Editing of PDFs works these days, but it's expected to be less than perfect. The typical use case for SVG, on the other hand, is as an exchange format for vector graphics, say for post-processing the drawing in a full blown vector graphics editor such as Inkscape.

However, the PDFs produced by Cairo are actually more suitable to editing than the SVGs. When opening a cairo-generated SVG in Inkscape, any user will quickly be frustrated by the fact that text is not text but a container object holding a bunch of individual characters. This is illustrated by numerous bug-reports filed with applications relying on Cairo to create vector graphics files (e.g. the Cairo device implementation for R).

The only use case I see currently where exact glyph positioning would be desirable is when using cairo to generate SVGs to be used in websites. In this case I'd still argue for the text tag, simply because all the glyph tags make the SVG unreasonably large.

(In reply to comment #21)
> 
> As an application developer I chose Cairo not least because it promised to
> make it trivial to produce PDF and SVG exports of the graphics my software
> renders on screen. The typical use case for PDF is printing. Here, exact
> reproduction of the rendered output is indeed critical. Editing of PDFs
> works these days, but it's expected to be less than perfect. The typical use
> case for SVG, on the other hand, is as an exchange format for vector
> graphics, say for post-processing the drawing in a full blown vector
> graphics editor such as Inkscape.
> 
> However, the PDFs produced by Cairo are actually more suitable to editing
> than the SVGs. When opening a cairo-generated SVG in Inkscape, any user will
> quickly be frustrated by the fact that text is not text but a container
> object holding a bunch of individual characters. This is illustrated by
> numerous bug-reports filed with applications relying on Cairo to create
> vector graphics files (e.g. the Cairo device implementation for R).

+1

I actually export to PDF and then go through the inkscape PDF importer in order to recover editable text.

Is there no chance of getting this in?

What’s the point of generating an editable format when the most important thing one would want to edit, namely the text, is baked into shapes?

If I want incontrovertible faithfulness I can generate PNG.

What is the status of this issue?
"<text>" would be really great.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/253.