I wrote:
Manuel Mall wrote:
> There is no need to expose creation of the Space/Word areas directly
> to TextLayoutManager either. TextArea could easily expose an addWord
> and an addSpace method instead of the monolithic setText. In the end
> it probably boils down to me arguing that the setText logic currently
> in TextArea IMO should be in TextLayoutManager (and probably based on
> its data structures) because it is an operation closely coupled to
> layout and not to areas.
Ok.
Done:
http://svn.apache.org/viewcvs.cgi?view=rev&rev=328882
I added a boolean attribute in SpaceArea that is true for adjustable
spaces (at the moment it is not used, but I will fix it soon).
At the moment the offset in SpaceArea and WordArea are unused, but this is
how I think they could be used: if, because of the rounding in the
adjustment computation, the applied adjustment is different than the
needed one, the TextLM should distribute this difference (a few
millipoints) among the SpaceAreas and / or WordAreas, setting their
offset.
The renderers will use this according to their own adjustment rule: for
example the PDFRenderer would add it to the text adjustment if the
character is multibyte.
The offset could come in handy for the cjk support (bug 36977): in this
case there are no adjustable spaces, and if text is justified all the
difference between line width and unadjusted character width could be
handled modifying the offsets of some special characters.
Regards
Luca
