Bug 38516 - Make Text in generated SVG file selectable
Summary: Make Text in generated SVG file selectable
Status: RESOLVED MOVED
Alias: None
Product: cairo
Classification: Unclassified
Component: svg backend (show other bugs)
Version: 1.10.2
Hardware: Other All
: medium enhancement
Assignee: Emmanuel Pacaud
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-21 03:16 UTC by Joachim Breitner
Modified: 2018-08-25 13:53 UTC (History)
7 users (show)

See Also:
i915 platform:
i915 features:


Attachments
patch from Jonathan Marchand (4.84 KB, patch)
2011-06-21 05:31 UTC, Emmanuel Pacaud
Details | Splinter Review
show_text_glyphs support (51.74 KB, patch)
2011-09-16 01:14 UTC, MIYABE Tatsuhiko
Details | Splinter Review
Smaller patch (39.43 KB, patch)
2011-09-16 03:09 UTC, MIYABE Tatsuhiko
Details | Splinter Review
Changed unit-per-em to 2048. (36.63 KB, patch)
2011-09-17 04:56 UTC, MIYABE Tatsuhiko
Details | Splinter Review
Apply some fix (33.05 KB, patch)
2011-09-20 06:19 UTC, MIYABE Tatsuhiko
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Joachim Breitner 2011-06-21 03:16:23 UTC
Not sure if this is possible, but if it is, it would be nice:

The PDF backend has text included as such, e.g. selectable and searchable. But for SVG files, the text information is lost, as the letters are included as glyphs. This can be seen by comparing http://www.joachim-breitner.de/various/pdf_screenshot_3.svg and http://www.joachim-breitner.de/various/pdf_screenshot_3.pdf.

It would be nice if text rendered into a SVG file is still somehow present.
Comment 3 Emmanuel Pacaud 2011-06-21 05:31:41 UTC
Created attachment 48224 [details] [review]
patch from Jonathan Marchand
Comment 4 Behdad Esfahbod 2011-06-21 09:02:28 UTC
The patch is wrong as it loses the glyph information!
Comment 5 MIYABE Tatsuhiko 2011-09-16 01:14:01 UTC
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 6 MIYABE Tatsuhiko 2011-09-16 01:16:50 UTC
Comment on attachment 51255 [details] [review]
show_text_glyphs support

In addition, this patch is more efficient to specify fill and stroke style.
Comment 7 Emmanuel Pacaud 2011-09-16 01:30:50 UTC
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.
Comment 8 MIYABE Tatsuhiko 2011-09-16 03:09:19 UTC
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.
Comment 9 Behdad Esfahbod 2011-09-16 09:48:56 UTC
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.
Comment 10 MIYABE Tatsuhiko 2011-09-17 04:56:28 UTC
Created attachment 51287 [details] [review]
Changed unit-per-em to 2048.
Comment 11 MIYABE Tatsuhiko 2011-09-17 05:05:59 UTC
+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?
Comment 12 Adrian Johnson 2011-09-17 05:39:34 UTC
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.
Comment 13 Behdad Esfahbod 2011-09-17 08:47:05 UTC
(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.
Comment 14 MIYABE Tatsuhiko 2011-09-17 22:45:53 UTC
> 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.
Comment 15 Behdad Esfahbod 2011-09-19 07:53:34 UTC
(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?
Comment 16 MIYABE Tatsuhiko 2011-09-20 06:19:50 UTC
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.
Comment 17 Tobias Wolf 2011-10-15 02:08:35 UTC
Is this patch finished?

Having text a text would really make touching up plots for print much easier.
Comment 18 Emmanuel Pacaud 2011-10-16 13:01:39 UTC
> +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.
Comment 19 Tobias Wolf 2012-02-25 12:50:36 UTC
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.
Comment 20 Paul Menzel 2012-07-23 15:48:55 UTC
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
Comment 21 elmar 2013-10-16 19:41:42 UTC
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.
Comment 22 John Stowers 2013-11-02 20:06:30 UTC
(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.
Comment 23 Tobias Wolf 2014-02-20 04:03:28 UTC
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.
Comment 24 doppelbauer 2017-05-05 10:05:40 UTC
What is the status of this issue?
"<text>" would be really great.
Comment 25 GitLab Migration User 2018-08-25 13:53:53 UTC
-- 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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.