I realize a lot of you are super busy lately, and I would like to get to IRC sometime soon to discuss these ideas with you.  But if anyone has had a chance to skim over the below information, I would like to know if you feel this is a worthwhile direction to take text over the summer, or if you think other items are more important.  I definitely want to ensure that you guys can benefit as much as possible from any contributions I can make.

Thanks :)
Gail


Gail Carmichael wrote:
Hi everyone,

I was hoping to get some feedback on the kind of things I would like to work on for GSoC this year.  The first portion of the summer should be spent on legalizing flowed text, as we established earlier.

>From my application last year:

As seen on Inkscape’s Wiki:

    When flowed text support was added to Inkscape, it was conformant to the then-current unfinished draft of SVG 1.2 specification (and was always described as an experimental feature). Unfortunately, in further SVG 1.2 drafts, the W3C decided to change the way this feature is specified. Currently SVG 1.2 is still not finished, and as a result, very few SVG renderers currently implement either the old or the new syntax of SVG 1.2 flowed text.

Therefore, work must be done to flowed text if it is to be SVG compliant.

As an interim option to legalize flowed text until the new SVG spec is standardized, Inkscape should provide some plain text for renderers that don’t implement flowed text to use in addition to tags for the current flowed text implementation.

Is this still the most desirable approach to the problem?

Next, because it is not expected to have the flowed text problem take the whole summer, I would like to know what the best second issue to tackle would be.  There were a lot of great ideas like bulleted lists and so on, but these would take at least a whole summer, so I don't think they are appropriate to do now.  I have been in contact with the Pango devs regarding the fact that the structure we use to store our fonts is rather limiting in what variants it can describe, and this is one response I received:

My guess is the best way to handle this w Pango would be through OpenType
features & lookups i.e. to include the swash variant glyphs in the base font
and have those accessed through OpenType features and lookups - which could
be either contextual or user selected. Having *separate* alternative "fancy" fonts with swash / small caps / etc. fonts is the old way of doing things - if you think about it that way, is much more limited.

For user selected / discretionary OT features the application (Inkscape)
would need some kind of interface /menu through which the user could
apply the features she wanted to.

WRT CSS - there has been some serious discussion off and on over several years (on the OpenType list, CSS related lists and other places) about specifying - or applying OpenType features through CSS.

But another response seemed somewhat less promising:

Swash variants is something that can be handle through OpenType
features. Although we still need the interface and the API to apply
them.

Even when that's done there are plenty of fonts out there that have
Swash variants, or Caption, Heading, Display, Bubble, Outline, and
whatever exotic variant that cannot be handle with OT features. Look
at Adobe Font Foolio for example. Some of its font families have
Caption, Display and Subhead variants. We need a way to handle those.
For example Adobe Jenson Pro has 4 variants for Regular. fc-list will give:
Adobe Jenson Pro,Adobe Jenson Pro Subh:style=Subhead,Regular
Adobe Jenson Pro:style=Regular
Adobe Jenson Pro,Adobe Jenson Pro Disp:style=Display,Regular
Adobe Jenson Pro,Adobe Jenson Pro Capt:style=Caption,Regular
These have different pairs of preferred names and legacy names, yet
are rendered as the same. Something can be fixed there.

The OT 1.5 specifications added two more nameID to support these
non-CSS variants, or non-weight-width-slope (non-WWS) variants, to
make it easier by splitting them into different font families. But
that will only take place in future fonts. People need to be able to
use today's fonts today.

So, a possibility for the second part of the summer is to research our best move in this matter.  It is certainly not something that can be determined in a few days IMO - it will involve some pretty heft changes in terms of how fonts are stored in Inkscape, and could benefit from some refactoring of that code.  The best result of this portion of work would probably be a detailed document outlining what is to be done.  This would also ensure that the "work" doesn't conflict with the major refactoring project.

What do you guys think? Would this be a reasonable plan or should I instead try to tackle another smaller problem after the flowed text issue?

Thanks for making it this far in a pretty long email :)

Gail