Problems creating a field in LC8 DP16

[-hh]

William,

meanwhile I tested this in depth and must say that you are
right with that: The formattedWidth and formattedHeight don't
show the exact boundaries, as you wish.

But from my knowledge of TeX I know, that this isn't obtainable
for fonts that don't have an extremely optimized metric. This
isn't even solvable by "pure" typesetting engines (nor by LC).

The formattedWidth is meanwhile pretty good measured.
[It has some problems with extreme slanted fonts.
That's the problem of non-perfect text-metric of the fonts.]

The formattedHeight is *better than ever*, but has still some
problems with interline-spacing at top or at end of strings.

So, with the final version of script you probably have to wait
for stable 8.0.0 (or 8.0.1) -- there is too much "in motion"
with the new "text engine". Peter certainly could say more here.

Perhaps you should report this as bug, so that they know
there are, despite their improvements, still problems?

We should use for demos of these problems, to be fair with respect
to font-metrics, a high-quality otf/ttf-font (for example "Skia").

Hermann

p.s. I was some time ago preparing a stack for the Raspi-stacks
collection that shows the exact boundary box of the
"outer opaque region" of a transparent object. I'll expand it now to
test also the formattedHeight and formattedWidth of a text-display.



Wprothero wrote
> Is this a bug? Shouldn’t the formattedHeight and formattedWidth show the
> text? I’m content to use my margins adjustment, but hope it doesn’t need
> to be revisited in the future. If so, it’s a small thing, but...





--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Problems-creating-a-field-in-LC8-DP16-tp4702326p4702354.html
Sent from the Revolution - User mailing list archive at Nabble.com.