Re: [Inkscape-devel] Roadmapping for 0.39-0.50
Probably the best sequence to attack this in might be:
I agree with all points except:
- start emplying Pango to perform text layout for e.g. SPText and
friends
What is meant by this? What we DO need from Pango is proper glyph composites and contextual forms (in some languages, different glyphs are used for the same char in different positions), and that fits into the "get glyphs from Pango into the renderer" part. As for text layout proper, I see no need to rewrite it once again, with all the spacing and kerning that was added recently. In any case, compliant text layout is only possible if you know the document tree context (remember the example where one part of the dx/dy values for a string is taken from its parent, the other from grandparent, etc.?), and I doubt Pango is really capable of that.
_________________________________________________________________ http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI...
On Sun, 2004-04-04 at 21:26, bulia byak wrote:
As for text layout proper, I see no need to rewrite it once again, with all the spacing and kerning that was added recently.
Have we tested the new spacing and kerning code with vertical text? Also, what about RTL spans, for example in Hebrew or Arabic? What about Ruby? [ actually I'm not sure offhand if Pango does Ruby or not ] I believe some Indic scripts also have special layout requirements...
Anyway, Pango has a complete layout engine that supports a lot more than we do ourselves, SVG-specific features aside.
In any case, compliant text layout is only possible if you know the document tree context (remember the example where one part of the dx/dy values for a string is taken from its parent, the other from grandparent, etc.?), and I doubt Pango is really capable of that.
We can perform dx/dy fixups (and other SVG-specific adjustments) after performing the initial layout with Pango.
Basically, this involves registering custom Pango attributes which we can use to tie sections of pango text to the appropriate SVG context. After Pango has computed a layout, we should be able to retrieve those attributes to perform SVG-related fixups.
In any case, I listed this last because it is not something really necessary to be part of the intial Pangoization, IMO. But it is something I would like to investigate in the future.
-mental
Will Pango allow us to have a block of text with various spacing and different fonts, styles flowing together? For example, I hope that our implementation of spacing is not only limited to lines, but so that one could select/highlight text and then change the selection's font, spacing, size and allow that text be edited the same as our current implementation.
Thoughts...
Our interface for text manipulation is not so good, and what I would consider one of our weakest features (along with import/export). Our shape editing is great and the usability and efficiency is excellent!
IMHO, we need a few features to make our text system production-ready:
1.) smaller text/font dialog that is more well thought out, and dependent on direct editing of text on the canvas. I think we should get rid of the in-window editing. Also, we should figure out how to detect if text is on the clipbboard and paste a text object. This is annoying problem. The text/font palette should be wholly moved to the secondary toolbar and operate on the selection like the current 2ndary toolbars on the shapes.
2.) text inside a shape. I know NJH has this working and is prolly waiting for pango-ification. For design work this is HYPER necessary. Several of my artist/designer friends are waiting on Inkscape till this is implemented, as you can then actually layout writings. (to take this further, multiple pages of text would put us beyond illustrator and freehand!)
To recap, and this is a point of contention, all font features should be selectable with the font tool as a selection of the text (highlighting characters in a block). The text/font interface (2ndary toolbar) will then show the features of the selected text and allow a user to alter the selection. This should also work on a selected block of text or multiple blocks of text. To represent this properly in the interface when blocks of text are selected with different features, then the input window on the interface should either be black or have an asterix to identify that there are different styles. If we implement this, then we will reduce drag on the users.
IMHO I think that our policy should be direct editing on the canvas where possible across new features. The sub-windows are not a good idea. Why should users have to learn another sub-interface? If you look at the best design apps, they support this concept and I think our secondary toolbar is super good for this, as it can be torn off and exist as a palette as well. Generally though, our dialogues are way too big.
Jon
On Tue, 2004-04-06 at 11:08, MenTaLguY wrote:
On Sun, 2004-04-04 at 21:26, bulia byak wrote:
As for text layout proper, I see no need to rewrite it once again, with all the spacing and kerning that was added recently.
Have we tested the new spacing and kerning code with vertical text? Also, what about RTL spans, for example in Hebrew or Arabic? What about Ruby? [ actually I'm not sure offhand if Pango does Ruby or not ] I believe some Indic scripts also have special layout requirements...
Anyway, Pango has a complete layout engine that supports a lot more than we do ourselves, SVG-specific features aside.
In any case, compliant text layout is only possible if you know the document tree context (remember the example where one part of the dx/dy values for a string is taken from its parent, the other from grandparent, etc.?), and I doubt Pango is really capable of that.
We can perform dx/dy fixups (and other SVG-specific adjustments) after performing the initial layout with Pango.
Basically, this involves registering custom Pango attributes which we can use to tie sections of pango text to the appropriate SVG context. After Pango has computed a layout, we should be able to retrieve those attributes to perform SVG-related fixups.
In any case, I listed this last because it is not something really necessary to be part of the intial Pangoization, IMO. But it is something I would like to investigate in the future.
-mental
On Wed, 2004-04-07 at 02:34, Jonathan Phillips wrote:
Will Pango allow us to have a block of text with various spacing and different fonts, styles flowing together? For example, I hope that our implementation of spacing is not only limited to lines, but so that one could select/highlight text and then change the selection's font, spacing, size and allow that text be edited the same as our current implementation.
pango would help a lot with that, though of course it would not do everything for us. One area where it is particularly helpful is knowing how many bytes/unicode codepoints to advance the cursor -- currently I believe we assume codepoints == glyphs, but the number of codepoints comprising a visible glyph can vary quite a bit in practice...
-mental
On Wed, 2004-04-07 at 08:34, Jonathan Phillips wrote:
Will Pango allow us to have a block of text with various spacing and different fonts, styles flowing together? For example, I hope that our implementation of spacing is not only limited to lines, but so that
one
could select/highlight text and then change the selection's font, spacing, size and allow that text be edited the same as our current implementation.
Thoughts...
Our interface for text manipulation is not so good, and what I would consider one of our weakest features (along with import/export). Our shape editing is great and the usability and efficiency is excellent!
Exactly.
IMHO, we need a few features to make our text system production-ready:
1.) smaller text/font dialog that is more well thought out, and dependent on direct editing of text on the canvas. I think we should
get
rid of the in-window editing. Also, we should figure out how to detect if text is on the clipbboard and paste a text object. This is annoying problem. The text/font palette should be wholly moved to the
secondary
toolbar and operate on the selection like the current 2ndary toolbars
on
the shapes.
Just was about to write a post, suggesting this, but then decided to first read the roadmapping.
2.) text inside a shape. I know NJH has this working and is prolly waiting for pango-ification. For design work this is HYPER necessary. Several of my artist/designer friends are waiting on Inkscape till
this
is implemented, as you can then actually layout writings. (to take
this
further, multiple pages of text would put us beyond illustrator and freehand!)
That'd be great! Inkscape could actually beocome a desktop publishing app. I'm not sure though, if that might not bloat the project a little too much. As a gnome user I'm no friend of scribus, really, cause it's qt, but dtp should probably be done by another app. That app could be a fork of inkscape though.
To recap, and this is a point of contention, all font features should
be
selectable with the font tool as a selection of the text (highlighting characters in a block). The text/font interface (2ndary toolbar) will then show the features of the selected text and allow a user to alter the selection. This should also work on a selected block of text or multiple blocks of text. To represent this properly in the interface when blocks of text are selected with different features, then the
input
window on the interface should either be black or have an asterix to identify that there are different styles. If we implement this, then
we
will reduce drag on the users.
Yes, PLEASE!
IMHO I think that our policy should be direct editing on the canvas where possible across new features. The sub-windows are not a good
idea.
Why should users have to learn another sub-interface? If you look at
the
best design apps, they support this concept and I think our secondary toolbar is super good for this, as it can be torn off and exist as a palette as well. Generally though, our dialogues are way too big.
I learned to like the secondary toolbar. But there's still so much more it could do :) E.g. I'd like to see the document settings in the secondary toolbar, if there's nothing selected and the chosen tool has no default settings or the such. Oh, and yes, you're right, dialog _are_ way to big, at least on a 1024x768 screen.
Regards
David
On Fri, 2004-04-09 at 10:00, David Christian Berg wrote:
That'd be great! Inkscape could actually beocome a desktop publishing app. I'm not sure though, if that might not bloat the project a little too much. As a gnome user I'm no friend of scribus, really, cause it's qt, but dtp should probably be done by another app. That app could be a fork of inkscape though.
DTP isn't a goal for Inkscape, no. If someone wants to fork at some point, they're certainly welcome to do so.
Qt or no, I personally consider Scribus a sister project; the two projects have been working closely together, and will continue to do so.
-mental
Jonathan Phillips wrote:
2.) text inside a shape. I know NJH has this working and is prolly waiting for pango-ification. For design work this is HYPER necessary. Several of my artist/designer friends are waiting on Inkscape till this is implemented, as you can then actually layout writings. (to take this further, multiple pages of text would put us beyond illustrator and freehand!)
The problem is that the SVG spec provides an algorithm, so my algorithm is not actually useful here, despite being technically superior. I'm not supposed to be working on non-research stuff so someone else is going to have to implement text-in-shape. The important section is: http://www.w3.org/TR/2004/WD-SVG12-20040318/#flow
njh
The problem is that the SVG spec provides an algorithm, so my algorithm
isn't it possible to store the layout as x/y attributes?
going to have to implement text-in-shape. The
already did once, maybe i can ressurect some of the code
important section is: http://www.w3.org/TR/2004/WD-SVG12-20040318/#flow
that's not final spec?
Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/
Dialoguez en direct avec vos amis grâce à Yahoo! Messenger !Téléchargez Yahoo! Messenger sur http://fr.messenger.yahoo.com
I would recommend posting comments to the svg w3c list about this if a problem because they are always actively debating shortcomings.
Fred, you will get 10,000 cool points for implementing text-in-shape.
What spec is multiple pages SVG in? I think that one is very cool as well and will put us ahead of illustrator and other apps...
Jon
On Tue, 2004-04-13 at 01:05, fred wrote:
The problem is that the SVG spec provides an algorithm, so my algorithm
isn't it possible to store the layout as x/y attributes?
going to have to implement text-in-shape. The
already did once, maybe i can ressurect some of the code
important section is: http://www.w3.org/TR/2004/WD-SVG12-20040318/#flow
that's not final spec?
Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/
Dialoguez en direct avec vos amis grâce à Yahoo! Messenger !Téléchargez Yahoo! Messenger sur http://fr.messenger.yahoo.com
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
--- Jonathan Phillips <jon@...235...> wrote:
What spec is multiple pages SVG in? I think that one is very cool as well and will put us ahead of illustrator and other apps...
its section 8 in the latest draft http://www.w3.org/TR/SVG12/#multipage
__________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/
participants (7)
-
bulia byak -
David Christian Berg -
fred -
John Cliff -
Jonathan Phillips -
MenTaLguY -
Nathan Hurst