[cairo] Inkscape eps export for Latex

[Behdad Esfahbod]

Hi Adrian,

Thanks for the mail.

On 08/30/2009 02:56 AM, Adrian Johnson wrote:
> Bernd Bandemer wrote:
>> Any ideas on a robust solution for this? I also noticed that the
>> roadmap for Cairo has enabling/disabling certain subsetters scheduled
>> for 2.12, but this is very far in the future... It would be great if a
>> solution can be found sooner.
>
> Currently as long as cairo is subsetting the font any hack based around
> substituting placeholder text will not work since the substituted text
> may use glyphs that are not in the subset.

I think psfrag substitutes the entire show operation with other Postscript 
code.  So subsetting in itself is not an issue.


> Possible solutions are:
>
> 1) Fix Inkscape
>
> The purpose of psfrag is to embed LaTex equations in the drawings.
> However Inkscape already provides this functionality with
> Extensions->Render->LaTeX formula. In a comment 12 on the Inkscape bug
> report [1] you pointed out that after embedding an equation in Inkscape,
> changing the font or font size requires requires reentering the
> equation. This appears to be because Inkscape converts the rendered
> equation to paths and embeds the paths in the SVG file.
>
> This could be fixed if Inkscape also embedded the LaTex equation in the
> SVG file and automatically rerendered it when the font is changed. I'm
> not an SVG expert but reading the SVG 1.1 specification there is a
> "Foreign namespaces and private data" feature that can be used for
> "Application-specific information so that authoring applications can
> include model-level data in the SVG content to serve their
> "roundtripping" purposes".

I think I agree with Bernd that such solutions break the batch-processing 
nature of TeX systems and are suboptimal.  If you want to change the formula 
in the drawing, instead of typing in vim and running make, you now need to 
open Inkscape, change something, export to EPS, run make.

Another option, one I like to see instead, is a solution similar to TeX's 
\special.  That is, have a way in cairo PS backend to inject arbitrary 
Postscript code.  The Inkscape can have a kind of external object placeholder 
that it would inject into cairo's output, and psfrag changed to understand 
that.  Similar features for PDF is also desired, but should be flexible enough 
to allow PDF forms, etc, for example.


> 2) Changes to cairo subsetting
>
> One of the items on my TODO list is to look into providing the option to
> allow embedding non-subsetted fonts in PDF. This is so the PDF output
> can be roundtripped though applications that modify the PDF file.

Right.  This would be a useful feature indeed.

> I am
> also planning to look into putting Latin text into a separate 8-bit
> subset from the 16-bit CID subset similar to what some other PDF files
> I've seen do.

Interesting.


> Implementing both of these features for the PostScript backend will
> allow generating PostScript files with "(Some ASCII text)" style
> PostScript strings. Using "Tj" instead of "show" is not the issue since
> psfrag already handles redefinitions of the show operator.

Implementing those two features will make it easy to output 
"(plaintext)"-style show or Tj, right, but the actual feature really is to use 
predefined encodings instead of identity encoding.  That can be done to 
subsetted fonts too.  For example, if we generate a separate subset for ASCII 
chars, then that subset may very well use the Latin1 encoding, even if 
subsetted (for Type 1, not TrueType).

Yet another useful feature would be to allow using the standard Postscript 
fonts.  I'm not sure how the API should look like.  Something like this:

   - Add PS/PDF-specific, or just generic font_face API to attach PS font 
family name to a cairo font face.  Then any backends who have a use for that 
information can use it,

   - Change cairo_ft_font_face_create_for_pattern() to set the PS name from 
the fontconfig pattern (needs fontconfig support [1] first, FC_PS_FAMILY),

   - Fontconfig configuration then can be written to attach standard PS family 
names (eg. "Helvetica") to substitutes (eg. "Nimbus Sans L").  Though, that 
would overwrite the original PS name.  Not sure.

Something like that.  The idea is to make the process transparent to Pango and 
higher-level.

Cheers,
behdad

[1] https://bugs.freedesktop.org/show_bug.cgi?id=18095