On 10/22/07, <b class="gmail_sendername">Robert O'Callahan</b> <<a href="mailto:robert@ocallahan.org">robert@ocallahan.org</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<span class="q">On Oct 23, 2007 11:21 AM, Behdad Esfahbod <<a href="mailto:behdad@behdad.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">behdad@behdad.org</a>> wrote:<br></span><div class="gmail_quote">
<span class="q"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> There is nothing preventing a library generating<br><div>> glyphs that have a negative advance width and so go in the<br>> logical order for right-to-left text, but it's not common
<br>> practice and most probably not very well supported.<br>><br>> If I understand you correctly, Gecko does this. For RTL runs we're<br>> calling cairo_show_glyphs with a glyph array whose x-offsets decrease
<br>> along the array.<br><br></div>You may want to revisit this. It adds lots of overhead both in X and<br>PS/PDF backends as each glyph need to be positioned individually.<br><div></div></blockquote></span><div>
<br>I'll keep that in mind, thanks.</div></div></blockquote><div><br>Alternatively, I was thinking that maybe the cairo backends can be "fixed". The idea is: ignore glyph width returned by font backend. Just use whatever that makes the first use of each glyph use *natural* width. That is, use (glyph[i+1].x - glyph[i].x) as natural width of glyph[i].index. However, while this may improve positioning for regular LtR runs, it doesn't work for RtL unless you put the glyph origin at the right of the glyph too, otherwise you'll be using the width of next glyph as in case of RtL, (glyph[i+1].x - glyph[i].x) is equal to -width(glyph[i+1].index).
<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><span class="q"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>> I think this is technically necessary for CSS compliance since CSS
<br>> says that all other things being equal, content later in a document<br>> ( i.e. in logical order) is higher in z-order than content earlier in<br>> the document.<br><br></div>Humm, not sure if it's necessary. Basically the order of glyphs in a
<br>single show_glyph() call should be irrelevant to the output. Any weird<br>combinations of operators and sources that violate that assumption?</blockquote></span><div><br>You may be right. But possibly with (future) user fonts where glyphs can have different colours? Sounds like a fragile assumption in general when you consider all possible backends etc.
</div></div></blockquote><div><br>Ok. I need to rethink the proposed API to see if we need to take this into consideration. It may just work, donno. Need to also check how PDF viewers deal with such text runs.<br><br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div>Rob<br></div></div><div><span class="e" id="q_115c9ddac850e599_6">
-- <br>"Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more?" Simon replied, "I suppose the one who had the bigger debt canceled." "You have judged correctly," Jesus said. [Luke 7:41-43]
</span></div></blockquote></div><br>-- <br>behdad<br><a href="http://behdad.org/">http://behdad.org/</a>