Thanks Michael and Stephan,
today I had the chance to look more carefully at that code and
understood that those positions are indeed word (and not paragraph) related.
Sorry for the noise.
Kind regards
Matteo
On 06/01/2015 06:20 PM, Michael Stahl wrote:
On 01.06.2015 09:45, Stephan Bergmann wrote:
On 06/01/2015 01:38 AM, Matteo Casalin wrote:
while converting some sal_uInt16 to sal_Int32 in
cui/source/dialogs/hyphen.cxx, I noticed that getHyphenationPositions()
returns a sequence of short/sal_Int16. The surrounding code suggests
that sal_Int32 would be more appropriate, but I see that this function
is listed in some .idl files and I can't say if changing it would break
some published API.
Looking at cui/source/dialogs/hyphen.cxx, you probably mean method
getHyphenationPositions of UNO interface
css.linguistic2.XPossibleHyphens. Which is indeed published, so cannot
be changed, for backwards compatibility.
So if there is really convincing reason to change this to e.g.
sequence<long>, either introduce a css.linguistic2.XPossibleHyphens2
etc. or discuss what the implications would be of incompatibly changing
css.linguistic.XPossibleHyphens.
Otherwise, best document that getHyphenationPositions unfortunately has
a poor return type for historic reasons, and ensure that its
implementations do reasonable things (e.g., do not include too large
positions in the returned sequence but emit a SAL_WARN instead).
i don't see much need to change this; ideally it should use "long" but
the interface is for hyphenation of a single *word* - those are usually
quite short. so the interface doesn't have to "work" for a 64k "word",
it's enough if it doesn't crash.
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
