openoffice-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: Letters change width when change position. Why?
Date Thu, 26 Feb 2015 04:31:57 GMT

On 25.02.2015 23:48, Keith Alcock wrote:
> APIers,
> This question was put to the forum without much luck getting an
> answer.  I hope that someone who knows the API might also know more
> about the internal workings of OpenOffice and can explain this
> phenomenon before I have to resort to source code.  Thanks.
> Some information about the resolution used for
> XTextViewCursor.getPosition() would help.  I can get the position of
> the cursor between two letters, but what is the resolution?  Can I
> measure the width any more accurately than taking the cursor position
> left and right of a letter?  See below...
> Keith
> I have written an extension that changes the colors of each letter
> in my document (for whatever reason).  They each have a different
> color, or at least a color different than either of their neighbors.
> For example, they can alternate between red and black.  When this runs
> for lines that are "tight" (have a very small amount of extra space
> before the margin), sometimes the word wrapping changes and the last
> word moves to the next line.  Should this be happening?  Why?  I
> happen to be working with Windows but will now try to reproduce this
> on another platform.
> Perhaps someone can say if this theory is true.  When there are no
> color changes between letters, a "run" of letters can be displayed or
> printed at once.  The operating system can do this after being told
> coordinates of where to start.  I'm not sure of the granularity of the
> coordinates, but it might be at the pixel.  Some of the letters within
> the run might begin between pixels and use antialiasing or subpixels
> to be spaced just right.  The operating system tells OpenOffice how
> long the run was, possibly rounded (up?) to the nearest pixel.
> OpenOffice then changes the color to red and draws the next character
> starting at some rounded or quantized pixel position.  If these
> rounding errors accumulate, the line of text gets longer and the last
> word is forced off.  Is this what happens?  Is there any easy way to
> prevent it?

I am not a Writer specialist, but alternating colors means that every 
letter is a text portion, compared to the whole line being a single text 
portion with equal attributes. Writer works internally in Twips and also 
layout is done in that unit, so I think it will not have to do with 
pixels at all - that discretisation for visualisation is done based on 
the layouting done in model coordinates (twips).
Still - Twips are an integer unit and thus summing up the width of all 
text portions with single letters may lead to a different result than 
the same in a single portion. But I think the reason for your problem is 
somewhere else.

Reasons may be e.g. font-specific handling e.g. a small 'o' in front of 
a 'T' or 'V' is moved closer to that letter to make it look more 
natural. This can probably only be done when these two letters are in 
one text portion which allows to assume they are in one 'word'. When 
some such font-specific exceptions are 'suppressed' by forcing each 
letter in an own text portion the layout will change.
This assumes that when each letter has different color that such 
font-specific optimizations are supposed not to be used and that each 
letter is to be handled independent of it's neighbour - a vaild 
assumtion and from my POV thus it's a valid consequence that the result 
looks different.
You can try this by using mentioned or similar combinations where enough 
space would be left to put directly neighboured letters closer together.



> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message