Re: [Inkscape-devel] Re: [cairo] Pango + cairo

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

Basically Unicode text layout is a nightmare!


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]