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.



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.


Reply via email to