Hi all,
I'm having Richard and mental review a patch with most of the tref stuff implemented. There are some small issues with it still and I will be fixing those issues, but I'd like to get the bulk of it versioned in the meantime. With this submission, you can open a document with a tref and see the content get updated when the source is modified.
Also, I wanted to get a clear consensus on what I should work on next. bulia mentioned that the CSS stuff would be good (bulia, can you remind everything precisely what you were referring to when you mentioned that so we are all clear?). Also keep in mind that I intend to stick around (though probably not as frequently) after the official program ends. So hopefully we'll see text improve more and more over the next year!
Finally, look for a blog post that summarizes my feelings on the program so far. You may find it interesting given that this is my first experience with open source.
Gail
On 7/9/07, Gail Banaszkiewicz <gbanaszk@...1686...> wrote:
Also, I wanted to get a clear consensus on what I should work on next. bulia mentioned that the CSS stuff would be good (bulia, can you remind everything precisely what you were referring to when you mentioned that so we are all clear?).
Actually, I think there are two very important things that need to be done with text. Whichever you take on next is fine with me :)
1. Overcoming the CSS limitations. The vocabulary of CSS font-family, font-weight, and font-style is very limited and fails to account for fancy variants such as "swoosh", "outline", etc. Even for simpler cases, a 1-to-1 correspondence between a font and a CSS description may be very hard to establish. For example, which of the "light", "ultralight", "heavy", "black", "ultra" etc. weights correspond to which font-weight values? Even if we establish such a correspondence for one font, a different font family may use the same weight terms quite differently. So, what we need is a very simple thing: an extension attribute that stores the _exact_ system name, including variant, of the font that the user selected. Of course all CSS values will still be written for compatibility as best we could, but Inkscape will give that extension attribute priority when selecting which font to use for a text object. Without this, it's unthinkable to use Inkscape for professional design where one often finds elaborate font families with dozens of variants.
2. Fixing the flowtext issue. It's a sore point because it's the only thing that makes our SVG files invalid. We need to move all the flowtext elements into Inkscape namespace and wrap them into an svg:switch whose alternative branch will be an automatically updated plain text equivalent of the flowtext, same as produced by Text > Convert to text command:
svg:switch <inkscape:flowRoot ...> ... flowtext ... </inkscape:flowRoot> svg:text ... same in plain text </svg:text> </svg:switch>
And then update all tools and commands to correctly work with this "protected" flowtext.
On Mon, 2007-07-09 at 13:53 -0400, Gail Banaszkiewicz wrote:
bulia byak wrote:
Actually, I think there are two very important things that need to be done with text. Whichever you take on next is fine with me :)
Any requests from the rest of you? Which of the two things that bulia mentioned would you rather see done?
You mean that we can't have both? :)
Personally I'd say that the flow text stuff should be completed first as it is a non-compliance issue. While the CSS stuff is really important for designers, I think our first goal should be major bugs.
--Ted
Ted Gould wrote:
You mean that we can't have both? :)
Eventually, good sir. Be patient ;)
Personally I'd say that the flow text stuff should be completed first as it is a non-compliance issue. While the CSS stuff is really important for designers, I think our first goal should be major bugs.
I believe that brings us to a tie - Richard, if I understood him correctly, votes for the CSS stuff.
On Mon, Jul 09, 2007 at 03:50:02PM -0400, Gail Banaszkiewicz wrote:
Ted Gould wrote:
You mean that we can't have both? :)
Eventually, good sir. Be patient ;)
Personally I'd say that the flow text stuff should be completed first as it is a non-compliance issue. While the CSS stuff is really important for designers, I think our first goal should be major bugs.
I believe that brings us to a tie - Richard, if I understood him correctly, votes for the CSS stuff.
As I've never delved enough to contribute code, and therefore _shouldn't_ have a say, I'd vote for the flow text thing, as it is biting me right now.
Jeff
Okay, I thought of another text task. I'm not sure if this is reasonable to be scoped with GSoC, but I thought I'd throw it out there so others could make the decision for me :)
One of the things that is annoying about text-on-a-path is that the characters get spaced pretty funky. I understand the spacing from an algorithms perspective, but from a visual perspective it just doesn't work. So, I (and I'm sure many others) end up manually kerning things so they look better. Inkscape should do the first pass at this automatically.
The Freetype folks have implemented in their library what they call the autohinter. Basically this was a work around for some Apple patents that disallowed them from implementing the full TrueType hinting. But, what it does is look at the shapes of the characters and tries to determine pretty good spacing for them, and it does a very workable job.
So, what I'd like is to steal the Freetype autohinter and put it in Inkscape. I don't think we'll be able to link to the code directly (which I'd prefer) because I think our internal models of things are different enough that converting them would be too painful. But, the algorithms should be roughly what we're looking for, and they've been tested and optimized over the years.
--Ted
Looks like I'm going to be looking at the CSS limitations rather than the legalization of flow text based on the recommendations of Richard and the fact that there was no overwhelming desire for one over the other (just slightly more desire for flowtext). Here is what bulia wrote earlier (msg continues below):
bulia byak wrote:
- Overcoming the CSS limitations. The vocabulary of CSS font-family,
font-weight, and font-style is very limited and fails to account for fancy variants such as "swoosh", "outline", etc. Even for simpler cases, a 1-to-1 correspondence between a font and a CSS description may be very hard to establish. For example, which of the "light", "ultralight", "heavy", "black", "ultra" etc. weights correspond to which font-weight values? Even if we establish such a correspondence for one font, a different font family may use the same weight terms quite differently. So, what we need is a very simple thing: an extension attribute that stores the _exact_ system name, including variant, of the font that the user selected. Of course all CSS values will still be written for compatibility as best we could, but Inkscape will give that extension attribute priority when selecting which font to use for a text object. Without this, it's unthinkable to use Inkscape for professional design where one often finds elaborate font families with dozens of variants.
There is one thing I've been getting myself confused about.
I have a couple of fonts with, for example, small caps (BernhardMod) and swoosh (Arrus) variants. In the font_factory::Families() function, the function pango_font_map_list_families() is used to retrieve the family names of fonts. These strings are then used in the "font-family" portion of the CSS style. I printed out the list of these names for my system, and found that instead of giving simply Arrus or BernhardMod, I get names that include the small caps or swoosh: BernhardMod ItSwash BT and Arrus SmCap BT.
If the fact that a font is small caps is part of its family name, it is clear that there is no need to include small caps in the CSS style (which would be supported if we wanted to add it there). The same goes for those variants that are not supported by CSS (outline, swoosh, etc). As it happens, the same argument can be used for various weights of fonts - whether a font is medium, light, narrow, wide - it seems to be included in the family name (ex Lithograph and LithographLight)!
If this is true, and I'm not missing something (which is certainly possible), why the need for the Inkscape: attribute?
Of course, all this changes if we update our UI to show actual font families (like just Arrus and BernhardMod), and all available styles of that family in another column.
Gail
On 7/19/07, Gail Banaszkiewicz <gbanaszk@...1686...> wrote:
If this is true, and I'm not missing something (which is certainly possible), why the need for the Inkscape: attribute?
Of course, all this changes if we update our UI to show actual font families (like just Arrus and BernhardMod), and all available styles of that family in another column.
That (UI) is one reason, and it's indeed a reason because all other design software does it the right way - family separate from all fonts within the family. We should do the same, or at least try to.
And the other reason is that we must still strive to provide an as-faithful-as-possible CSS specification for the font, even if we (Inkscape) won't use it. And that means, again, storing family name separately and the weight, style etc approximated by CSS properties.
bulia byak wrote:
That (UI) is one reason, and it's indeed a reason because all other design software does it the right way - family separate from all fonts within the family. We should do the same, or at least try to.
And the other reason is that we must still strive to provide an as-faithful-as-possible CSS specification for the font, even if we (Inkscape) won't use it. And that means, again, storing family name separately and the weight, style etc approximated by CSS properties.
Ok, good, I'm glad that I'm on the right page here. It looks like pango does not give the proper family name (please feel free to tell me otherwise if you know it is supposed to), so we will either need to find something else that can do this, or implement it ourselves. I assume the latter makes the most sense. I believe this is, relatively speaking, the only complex aspect of this task.
Thanks, Gail
On 7/19/07, Gail Banaszkiewicz <gbanaszk@...1686...> wrote:
Ok, good, I'm glad that I'm on the right page here. It looks like pango does not give the proper family name (please feel free to tell me otherwise if you know it is supposed to), so we will either need to find something else that can do this, or implement it ourselves. I assume the latter makes the most sense. I believe this is, relatively speaking, the only complex aspect of this task.
AFAIK, pango relies on some other libraries for fonts, and you may try to access those libraries - perhaps they provide more detailed or less monolithic information. Richard is a much better expert on these libraries than me, so he may suggest something.
participants (4)
-
bulia byak -
Gail Banaszkiewicz -
Jeffrey Brent McBeth -
Ted Gould