Hi,
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.
HTH!
Sincerely,
Armin
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscr...@openoffice.apache.org
For additional commands, e-mail: api-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscr...@openoffice.apache.org
For additional commands, e-mail: api-h...@openoffice.apache.org
