Hello everyone,
I'm Stojan Dimitrovski, a sophomore from Macedonia. I'm currently studying Computer Science at Ss. Cyril and Methodius University in Skopje.
I am considering applying for Inkscape on GSoC13.
I have a few ideas on improving the current text tool, particularly its user interface and some of its underlying features and implementation.
Here are some of those ideas:
- Typefaces' names should be rendered in the glyphs they describe if such exist. Example: Helvetica should be rendered in Helvetica, Garamond in Garamond, etc. Icon typefaces are rendered by the fallback GUI typeface on the system.
- There should be a live preview / comparison of typefaces interface which will allow for a better and faster typeface selection. Inspired by typeface pickers like the one in TypeKit or similar.
- There should be a character-preview of a typeface, which will show all of the glyphs in a typeface that are defined for it (and make it easy for those glyphs to be inserted into text). This is primarily useful when using icon typefaces (like Font Awesome from Twitter Bootstrap fame).
- Improved handling of different variants, weights, styles of typefaces. (Current implementation is a bit flaky handling this.)
- Implement a system for SVG font typesetting (actually be able to use the SVG fonts to render text inside Inkscape).
- Improve the SVG font interfaces, they really need some love.
I'd like to hear your suggestions and comments before I embark on doing mockups of the interface and thinking about the implementation.
I should also mention that I'm fluent in the technologies that Inkscape uses, especially in GTK+ (2, 3), GObject, GLib, C / C++. I have general knowledge of the SVG standard.
I've been using Inkscape since version 0.45 and have an understanding of its features and workflow.
The free-software movement, communities and development philosophies are not new to me.
Regards, Stojan Dimitrovski
On Thu, 2013-04-18 at 13:10 +0200, Stojan Dimitrovski wrote:
Hello everyone,
I'm Stojan Dimitrovski, a sophomore from Macedonia. I'm currently studying Computer Science at Ss. Cyril and Methodius University in Skopje.
I am considering applying for Inkscape on GSoC13.
Please do!
I have a few ideas on improving the current text tool, particularly its user interface and some of its underlying features and implementation.
Here are some of those ideas:
- Typefaces' names should be rendered in the glyphs they describe
if such exist. Example: Helvetica should be rendered in Helvetica, Garamond in Garamond, etc. Icon typefaces are rendered by the fallback GUI typeface on the system.
I am not so sure about this one. What if the typeface doesn't include the glyphs (say a Hindi font)? Some people have thousands of fonts. This might slow down the menu. We do have the option for a text sample next to the name.
- There should be a live preview / comparison of typefaces
interface which will allow for a better and faster typeface selection. Inspired by typeface pickers like the one in TypeKit or similar.
Good idea.
- There should be a character-preview of a typeface, which will
show all of the glyphs in a typeface that are defined for it (and make it easy for those glyphs to be inserted into text). This is primarily useful when using icon typefaces (like Font Awesome from Twitter Bootstrap fame).
See the Glyph dialog. It might need some tweaking.
- Improved handling of different variants, weights, styles of
typefaces. (Current implementation is a bit flaky handling this.)
Yes, I know there are still some bugs. This section of code was just completely rewritten.
- Implement a system for SVG font typesetting (actually be able to
use the SVG fonts to render text inside Inkscape).
I would love to see this but it is a hard problem. We use Pango for text layout and Pango does not have the ability to handle fonts that are not provided by the system. An effort to allow "User" fonts didn't get very far five years ago (you can find a patch on the web... but it is only the very beginning of what needs to be done). Cairo does have the ability to handle "User" fonts.
- Improve the SVG font interfaces, they really need some love.
I'd like to hear your suggestions and comments before I embark on doing mockups of the interface and thinking about the implementation.
I should also mention that I'm fluent in the technologies that Inkscape uses, especially in GTK+ (2, 3), GObject, GLib, C / C++. I have general knowledge of the SVG standard.
Excellent.
Tav
Welcome Stojan,
Please, may I add my thoughts.
I am considering applying for Inkscape on GSoC13.
Please do!
Seconded!
- Typefaces' names should be rendered in the glyphs they describe
Some people have thousands of fonts. This might slow down the menu.
Some pre-rendering and heavy sorting and filtering could solve this. See below.
- Improved handling of different variants, weights, styles of
typefaces. (Current implementation is a bit flaky handling this.)
Regarding weights and styles, there seems to be a lot of work to do to properly reign in the fonts selection. When I go to select a font, either I know the name of the font I'm after and I can type it in, or I don't know the name and what I really want is to browse.
This browsing work-flow needs, I think, to be implemented using a tree-type structure. Something akin to submenus where top level would be descriptive e.g. Serif, Symbol, Sans Serif, Comic etc. and from there I can select a font inside. The actual categorisation should use data available in the font definition and is debatable.
Actually what I'd like is something clever where the number of fonts is considered. If you only have < 20 fonts, a direct menu isn't a problem. If you have > 100 fonts in the serif category, then a further breakdown should be done somehow.
We use Pango for text layout and Pango does not have the ability to handle
Surely the answer is to stop using pango for text layout? Even if it took a large project or several GSoC projects to make a full switch. I'm not sure patching pango up when we already use cairo makes much sense.
Best Regards, Martin Owens
On Thu, Apr 18, 2013 at 5:00 PM, Martin Owens wrote:
This browsing work-flow needs, I think, to be implemented using a tree-type structure. Something akin to submenus where top level would be descriptive e.g. Serif, Symbol, Sans Serif, Comic etc. and from there I can select a font inside. The actual categorisation should use data available in the font definition and is debatable.
Are you referring to PANOSE?
Alexandre Prokoudine http://libregraphicsworld.org
On Thu, 2013-04-18 at 17:34 +0400, Alexandre Prokoudine wrote:
Are you referring to PANOSE?
I believe PANOSE is how you identify a font and thus categorise it according to a multi-dimensional dictionary set. Not sure if it's possible to use that as a basis to categorise fonts directly or if it would need some way to form with some priority as to what goes first.
Martin,
On Thu, 2013-04-18 at 09:00 -0400, Martin Owens wrote:
We use Pango for text layout and Pango does not have the ability to handle
Surely the answer is to stop using pango for text layout? Even if it took a large project or several GSoC projects to make a full switch. I'm not sure patching pango up when we already use cairo makes much sense.
Not realistic even if we had 10 GSoC projects. Text layout for non-Latin text can be extremely complicated. Pango is Cairo's text layout solution. Cairo's internal text API is considered a "toy" implementation, mostly for internal testing. See:
participants (4)
-
Alexandre Prokoudine -
Martin Owens -
Stojan Dimitrovski -
Tavmjong Bah