On Thu, 27 Oct 2005 11:04 pm, Luca Furini wrote: > 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 > Thank you
> 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). Why would you envisage this is required by the renderers? > > 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. > I see. Not sure if offset is the correct attribute though. Its stated purpose is for offsetting in the bpd direction. Overloading it with a different meaning is questionable. Instead for SpaceAreas we could use the IPD trait. Basically the LM tells the renderers via the SpaceArea 'I want an <ipd> mpt wide space here'. How the renderers make this space happen is up to them. Not sure if we should even consider distributing the rounding errors to the WordAreas. I would leave them with the SpaceAreas. A different approach would be not to have the space areas at all and simply set space-start/space-end traits on the word areas but that may be a bit radical (in the sense of its impact on the renderers) at this stage (but see below - CJK). Of course we could also use space-start/space-end traits on the SpaceAreas to model shrink/stretch instead of the IPD trait. May be that would be preferable? > 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. > Hmm, in the CJK case it appears most characters will become a single WordArea. If justification is required we either need to insert SpaceAreas between the WordAreas or add a property to the WordAreas. If we go for the additional property I would opt for setting space-start/space-end traits on those areas. This seems to me to be more in 'the spirit of XSL-FO'. > Regards > Luca Cheers Manuel
