Re: [Inkscape-devel] Re: [cairo] Pango + cairo
- From: Damon Chaplin <damon karuna uklinux net>
- To: Peter Moulder <Peter Moulder infotech monash edu au>
- Cc: Owen Taylor <otaylor redhat com>, njh hawthorn csse monash edu au, gtk-i18n-list gnome org
- Subject: Re: [Inkscape-devel] Re: [cairo] Pango + cairo
- Date: Sat, 26 Mar 2005 12:08:13 +0000
On Wed, 2005-03-23 at 10:39 +1100, Peter Moulder wrote:
> On Tue, Mar 22, 2005 at 01:13:29PM +0000, Damon Chaplin wrote:
>
> > Why does bidi reordering affect non-rectangular areas?
>
> Good question: this would depend on a couple of decisions as to how text
> should behave.
>
> The first is what to do with variable-height text. Ignore bidi for the
> moment in the following discussion, we'll start with plain left-to-right
> text. Say we're fitting into the middle of a circle or wide ellipse,
> and a word in the middle of the sentence is much taller (logical rect)
> than the rest of the sentence. I was assuming that we'd let the small
> words at the beginning & end of the sentence fill to very near the tips
> of the ellipse (i.e. so long as the logical rectangle of each glyph is
> within the ellipse), but perhaps we'd instead want the bounding box of
> the line to fit entirely within the ellipse.
I'd certainly vote for using the bounding box :)
It would be much simpler to provide other ways of letting the user tweak
the layout, like letting them adjust the text's area slightly.
> The other question relates to what to do if there are gaps in the spans.
> E.g. suppose the top edge is bumpy/spiky, or suppose we're flowing
> around a small picture/hole placed in the middle of the paragraph.
> I was assuming that a gappy line would be laid out as if it were a single
> line but just avoiding the gap. This is especially reasonable if the
> gap is very small (e.g. just the tip of a spike/bump intruding into the
> line). With this assumption, bidi affects what words go before/after
> the gap.
Yes, this is another nasty problem. It needs quite a different algorithm
- something like:
(1) select a potential line break position.
(2) reorder bidi text.
(3) try to fit words into different parts of the line.
(4) calculate a score according to how well it fits.
That would be quite a bit more complicated than my current code.
> An alternative is to let gaps divide the line into multiple logical
> "lines" that happen to be placed next to each other (sharing a
> baseline). This does raise the question of which sub-line should get
> the first word of the full line; so bidi may affect us somewhat even
> with this alternative.
I think DTP apps typically let you choose either method, so you probably
need to support both. The 'multiple lines' option is simpler to do
though.
Basically Unicode text layout is a nightmare!
Damon
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]