Issue 22540 - Character spacing / kerning inaccurate and varies
Summary: Character spacing / kerning inaccurate and varies
Status: ACCEPTED
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: OOo 1.1
Hardware: PC All
: P4 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
: 23853 25553 (view as issue list)
Depends on:
Blocks:
 
Reported: 2003-11-17 13:43 UTC by jameslee
Modified: 2017-05-20 11:25 UTC (History)
8 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Simple OOo docs containing "aaaaaaaaaa" (5.56 KB, application/octet-stream)
2003-11-17 13:44 UTC, jameslee
no flags Details
Print of OOo file, looks yuk and note the xshow parameter. (5.05 KB, application/postscript)
2003-11-17 13:47 UTC, jameslee
no flags Details
example document (8.34 KB, application/vnd.oasis.opendocument.text)
2010-10-12 23:38 UTC, 400guy
no flags Details
two colons clearly visible (62.88 KB, image/png)
2010-10-12 23:39 UTC, 400guy
no flags Details
first colon obscured (50.59 KB, image/png)
2010-10-12 23:39 UTC, 400guy
no flags Details
two colons visible again (49.02 KB, image/png)
2010-10-12 23:40 UTC, 400guy
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description jameslee 2003-11-17 13:43:47 UTC
Whilst checking some suspect character kerning I noticed the character spacing
is inaccurate and varies. See attached examples. I know "aaaaaaaaaa" is not a
popular word however it simply demonstrates the inter-character positioning
errors.

The data for xshow contains "21 23 21 23 21' which causes noticeable gaps in the
text when printed. (I think the width of an 'a' at this scale is 22.2). Note
2/22 is the positional error and at 9% of the character width is significant.
Comment 1 jameslee 2003-11-17 13:44:48 UTC
Created attachment 11341 [details]
Simple OOo docs containing "aaaaaaaaaa"
Comment 2 jameslee 2003-11-17 13:47:29 UTC
Created attachment 11342 [details]
Print of OOo file, looks yuk and note the xshow parameter.
Comment 3 mci 2003-12-22 18:21:16 UTC
Hi hdu,

I think this is something for you...

It's about "dancing characters" and inaccurate spacings between characters...

The Characters "dance" if you give a single character a new colour.
Undo this, redo it ... and you can see the characters dance...

After consultation with us we found out that 
this is related to the Internal Issue 109377 ...
Comment 4 hdu@apache.org 2004-01-06 10:36:00 UTC
HDU->JamesLee: To get better formatting for the printer please enable the
checkbox in the menue item
Tools -> Options -> TestDocument -> General -> UsePrinterMetricsForFormatting
and if possible increase the printer device resolution in
File -> PrinterSettings -> Advanced -> Device -> Resolution

Since version 1.1 OOo defaults to disable printer metrics for formatting,
because most users don't understand why the formatting would change when they
use a different printer or when they modify some printer settings like device
resolution.

Quantization errors are inevitable when dealing with integer coordinates. One of
the quantization errors is due to Writer working in TWIPS instead of reference
device pixels. The other quantization error occurs when converting TWIPS back to
device coordinates. OOo's VCL layer currently prefers to minimize the
quantization errors of absolute glyph positions instead of minimizing the
quantization error of relative positions of neighbouring glyphs.

E.g. the Writer thinks that according to the printer independent reference
device the optimal positions for the a's (relative to the left border) should be
1707+0, 1707+105, 1707+211, 1707+316, 1707+422,...
VCL calculates these TWIPS values back to device units which are
unrounded 355.62+0.0, 355.62+21.5, 355.62+43.58, 355.62+65.46, 355.62+87.54, ...
and rounded 356+0, 356+22, 356+44, 356+65, 356+88, ... This is where the deltas
of 22, 22, 21, 23 you observed come from.

HDU->FME: how about using pixel units of the reference device for formatting
instead of TWIPS? This would eliminate the quantization errors for printer
dependent formatting completely. For printer independent formatting also a lot
of quantization errors would disappear.
Comment 5 frank.meies 2004-01-06 11:36:14 UTC
FME: Unfortunately the writer core (as well as the other applications) depends
on using twips.

[...] OOo's VCL layer currently prefers to minimize the
quantization errors of absolute glyph positions instead of minimizing the
quantization error of relative positions of neighbouring glyphs. [...]

You say 'currently'. Is this going to be changed? This seems to be the problem.
Comment 6 hdu@apache.org 2004-01-06 13:13:39 UTC
HDU->AMA: Now it's up to you. Choose one if any
 - when the q-error of relative positions is minimized => "dancing characters" 
 - non-TWIPS formatting
 - floating point formatting
Comment 7 jameslee 2004-01-07 11:33:42 UTC
On 06/01/04, 10:36:00, <hdu@openoffice.org> wrote regarding [Issue 22540] 
Character spacing inaccurate and varie:

> and if possible increase the printer device resolution in
> File -> PrinterSettings -> Advanced -> Device -> Resolution

Yes, this is changing the output resolution and I see what OOo is doing is very
good. (Compare with the MSW HTML output I saw yesterday that specifies positions
to 0.001pt, ha,ha,ha!!!) The default is 300dpi and the page scale is set to 0.24
(72 300 div) and integers are used at that scale. I like! ...but the "toothy"
look is clearly visible to my eye when printed on a 1200dpi printer and it is
the double rounding of the relative move causing it, see below...


> Since version 1.1 OOo defaults to disable printer metrics
> for formatting, because most users don't understand why the
> formatting would change when they use a different printer
> or when they modify some printer settings like device
> resolution.

I'm one of them. I understand why the print output file is different, I
understand why different screens render the preview differently, but I don't
understand why the internal concept of theoretical positioning in the document
changes, eg, the page breaks shift when output device is changed. This is a
major problem if documents are to be exchanged. OOo is too WYSIWYG. What I want
is what the document author intended, not what the author sees, nor what I see.
The screen view, paper print or PDF export are simply the devices' best attempts
at showing what the author intends. Each are just views of the same thing and
should not change it.



> E.g. the Writer thinks that according to the printer independent
> reference device the optimal positions for the a's (relative to
> the left border) should be
> 1707+0, 1707+105, 1707+211, 1707+316, 1707+422,...
> VCL calculates these TWIPS values back to device units which are
> unrounded 355.62+0.0, 355.62+21.5, 355.62+43.58, 355.62+65.46,
> 355.62+87.54, ...
> and rounded 356+0, 356+22, 356+44, 356+65, 356+88, ... This is
> where the deltas
> of 22, 22, 21, 23 you observed come from.

The above example rounds the relative move then differences it.

That is the problem, the absolute positions need to be rounded to device
integers and then the relative moves calculated.


Scaled floating point positions:
355.62+0.0, 355.62+21.5, 355.62+43.58, 355.62+65.46, 355.62+87.54
Totals as floating point:
355.62, 377.12, 399.2, 421.08, 443.16
Round the totals to integers:
356, 377, 399, 421, 443
Calculate the deltas:
21, 22, 22, 22

Comment 8 hdu@apache.org 2004-01-07 13:21:31 UTC
>> Since version 1.1 OOo defaults to disable printer metrics
>> for formatting...
>
>[snipped]
> The screen view, paper print or PDF export are simply the devices' best
> attempts at showing what the author intends. Each are just views of the same
> thing and should not change it.

Yes, this is why the default changed to printer independent formatting. For low
resolution printers the printer optimized formatting looks much better of
course. For todays higher resolution printers the independent formatting is less
of an issue and the benefits you observed above outweigh the remaining
quantization problems.

HDU->PL: Maybe we should change the device resolution of the generic printer to
600 or 1200dpi? This will improve the output for the generic printer when
printer independent formatting is enabled.

> That is the problem, the absolute positions need to be rounded to device
> integers and then the relative moves calculated.

This is actually done. Sorry, I didn't make it clear the the second summand was
calculated that way. For the numerical example in my comment above the formula
XRelativePrinterPixels = ((1707 + XRelativeTwips) * 300.0 / 1440) - XPrinterBase
was used.

Here is the followup of the numerical example:
Writer wants them at 1707+0, 1707+105, 1707+211, 1707+316, 1707+422,...
=> in absolute printer pixels 355.63, 377.50, 399.58, 421.46, 443.54
=> rounded 356, 378, 400, 421, 444 => diffs 22, 22, 21, 23
So like I said the problem comes from Writer which advances them by either 105
or 106 Twips instead of 211 reference device units.

I like the discussion in this issue here, thank you for your thoughts.
Comment 9 hdu@apache.org 2004-01-07 13:36:54 UTC
Correction: Instead of
> Here is the followup of the numerical example:
in the comment above, I actually wanted to write:
"Here is an alternative view of the numerical example"
Comment 10 jameslee 2004-01-08 11:03:57 UTC
OK.
So the problem is the double rounding error accumulating.

+++++++++++++++++

First, let me clarify the numbers. A Times-Roman 'a' is 444 units wide in the
AFM tables:
/opt/OpenOffice.org1.1.0/share/psprint/fontmetric/Times-Roman.afm

and in 2 fonts I tested:

/Times-Roman 1000 selectfont
0 0 moveto
(a) show
currentpoint pop =


That means the width (motion to next character) of a 12 point 'a' at 1440 dpi is:

444 1000 div 12 72 div mul 1440 mul =

gives 106.56, which means the rounded positions differences should be either 106
or 107, not 105 or 106 as used in our examples.

+++++++++++++++++

Onward... I take it that OOo uses integer units internally, the Twips. So the
positions are scaled to 1440 dpi then rounded and stored as integers.

The device will position at its device units irrespective of how the position is
specified so it makes perfect sense, when a 300dpi device is used, to output in
300dpi increments. (It might not make sense to use 300dpi as the default.) 

The problem is the floating point position is rounded twice, first to Twips,
then output device units.

The way to avoid the first rounding causing the second rounding to move beyond a
Twips unit is to make sure the internal Twips units line up with the device
units. This can be done by using Twips device scale that has the device units as
common factors. Thus the ratio of device scale to Twips scale is an integer and
the output rounding thresholds correspond to the internal rounding thresholds
and rounding to an output unit won't move to another Twips integer.

I suggest you use 7200 (not 1440). This has factors of 72, 75, 100, 120, 150,
300, 360, 600, 720, 1200, 1440, 2400 - which covers most printers and screen
optimised fonts.

If it uses a 32bit signed integer to store the Twips units then by increasing
the scale 5 fold you won't run out of paper, it still gives a 7.5km range.

Comment 11 hdu@apache.org 2004-01-08 15:33:41 UTC
> Times-Roman 'a' is 444 units wide in the AFM tables

For printer independent formatting the fonts only available on the printer are
ignored. It is formatted against a fallback font, probably Thorndale or TNR.
They provide the 211 pixel advance width on a 600dpi ref device.

We are also considering to change the reference device to 1440dpi to get rid of
the RefDev->Twips rounding. Or making the reference device more independent of
any resolution. Also your idea to use a resolution of 7200dpi as an integer
multiple of the most important printer resolutions is great. On the other hand
metric compatibility to other competing applications and their legacy documents
has an even higher priority. It's all a delicate balance...

The 7200dpi resolution would loose some of its appeal when AMA decides that
Writer won't use float-Twips or non-Twips formatting. Then 1440dpi would have a
slight edge.

For now I still think that changing the default printer resolution to 600 or
even 1200 dpi has the highest benefit to risk ratio.
Comment 12 jameslee 2004-01-09 11:00:57 UTC
On 08/01/04, 15:33:42, <hdu@openoffice.org> wrote regarding [Issue 22540] 
Character spacing inaccurate and varie:

> For printer independent formatting the fonts only
> available on the printer are ignored.

Times-Roman is *not* only available on the printer.


> It is formatted against a fallback font,  probably Thorndale or TNR.

Neither Thorndale nor TNR are installed in my OOo.


> They provide the 211 pixel advance width on a 600dpi ref device.

For Times New Roman 'a' at 12 point scale on a 600dpi device the pixel advance
is 44.3848.

/TimesNew-Roman findfont /FontName get =
TimesNewRomanPSMT

/TimesNew-Roman 12 selectfont
0 0 moveto
(a) show
currentpoint pop
72 div 600 mul =
44.3848

Which is close enough to the Adobe Times-Roman advance and AFM value of 444.


Scaling to the units used previously and moving 2 steps:

/Times-NewRoman 12 selectfont
0 0 moveto
(a) show
currentpoint pop
72 div 1440 mul 2 mul =

Gives 213.047. I don't see where the 211 you quote is coming from. Please show
the derivation.



> For now I still think that changing the default printer
> resolution to 600 or
> even 1200 dpi has the highest benefit to risk ratio.

Yes for a >300 dpi device.

For a 300dpi device no. The device will round to the same places as OOo is
outputting the rounded units. The problem is the same.


+++++++++++++++++++++++

As far as I can see, (which is several AFM tables, 2 PostScript printers, an
MSWindows TT font, the GhostScript Nimbus Times clones) the width of a 1000
scale Times-Roman 'a' is 444.

I can't see why changing to/from printer independent formatting changes this.
Neither can I see why the page layout changes when the switch is made.

Comment 13 hdu@apache.org 2004-01-12 16:42:30 UTC
> Times-Roman is *not* only available on the printer.

Ok, but does OOo see it? Please enable View->OnlineLayout and check, if the
"Times-Roman" font is available in the font list. If not, you can add the font
using the spadmin tool (in OOo's program directory).

If neither Times-Roman, TNR or Thorndale wasn't available to OOo another
fallback font like e.g. Helvetica, maybe even a scaled X11 fonts gets used.

>> For now I still think that changing the default printer
>> resolution to 600 or
>> even 1200 dpi has the highest benefit to risk ratio.
>
> Yes for a >300 dpi device.
> For a 300dpi device no...

For a 300dpi device there are no drawbacks then...
Comment 14 jameslee 2004-01-13 10:10:34 UTC
> > Times-Roman is *not* only available on the printer.

> Ok, but does OOo see it? Please enable View->OnlineLayout
> and check, if the "Times-Roman" font is available in the
> font list. If not, you can add the font using the spadmin
> tool (in OOo's program directory).

(1) "Times" is on the menu of fonts on the writer frame.

(2) Times-Roman is *always* available on (PS) printers.

(3) OOo *always* know about it (widths and kerning) because
OOo includes its AFM file.


Spadmin is not picking up any Type1 fonts so I can't add another TR.

(Incidentally, I added Times New Roman(TT) and OOo substitutes a request for
Times Roman in the print file. That's not too bad as TNR is a good rip off of
TR, but I tried Arial(TT) and I get Helvetica! Call me simple but when I ask for
Arial I do it because I want Arial, if I wanted Helvetica don't you think I
would have used it?)


> If neither Times-Roman, TNR or Thorndale wasn't available to OOo another
> fallback font like e.g. Helvetica, maybe even a scaled X11 fonts gets used.

I don't understand this, "available" means 3 things: formatting information
(AFM), screen font for viewing and printer font. A scaled X11 font might get
used to *show* the document but how does that affect its layout or how it's
printed? In the case of TR, the later 2 availabilities are always satisfied.


> >> For now I still think that changing the default printer
> >> resolution to 600 or
> >> even 1200 dpi has the highest benefit to risk ratio.
> >
> > Yes for a >300 dpi device.
> > For a 300dpi device no...

> For a 300dpi device there are no drawbacks then...

... but no advances either.
Comment 15 philipp.lohmann 2004-01-13 10:57:13 UTC
Concerning your problem with spadmin and type 1 fonts: you need both the font
file (either pfb of pfa) and the afm file; the afm file must be in th same
directory as the font file or in an "afm" subdirectory, also its name must be
the same as the font file apart from the different extension.
Comment 16 jameslee 2004-01-14 11:21:26 UTC
> ------- Additional comments from pl@openoffice.org Tue Jan 13 02:57:13 -0800
2004 -------
> Concerning your problem with spadmin and type 1 fonts: you need both the font
> file (either pfb of pfa) and the afm file;

Got it.

I tried adding a Times-Roman but nothing happened.
I seem to have Times already.

If I rename the font it is added - but then it's not
Times, (just as Arial isn't Helvetica).

Comment 17 andreas.martens 2004-01-22 11:59:24 UTC
I think this thread runs out of control ;-)
The original problem seems to be a rounding problem. I don't want to change the
units we use in Writer (at least for the next release). For rounding problems we
should try to minimize the quantization of the absolute position.
I don't understand your example:
[..]
E.g. the Writer thinks that according to the printer independent reference
device the optimal positions for the a's (relative to the left border) should be
1707+0, 1707+105, 1707+211, 1707+316, 1707+422,...
VCL calculates these TWIPS values back to device units which are
unrounded 355.62+0.0, 355.62+21.5, 355.62+43.58, 355.62+65.46, 355.62+87.54, ...
and rounded 356+0, 356+22, 356+44, 356+65, 356+88, ... 
[..]
Why don't you first calculate the totals 1707, 1812, 1918, 2023, 2129,.. before
you convert TWIPS into device units?
I 
Comment 18 hdu@apache.org 2004-01-22 12:59:53 UTC
> I think this thread runs out of control ;-)

+1 from me

> Why don't you first calculate the totals...

This is how it is done today! The problem is the double rounding, which is
inevitable if the reference device, the Writer and the target devices have
different resolutions and still insist on using integer metrics.

Currently the handling is already optimized for cases where the reference device
is the target device. It has to be determined if in cases where a printer
independend reference device is used a TWIPS friendly resolution or
no-resolution device has sufficient layout compatibility with legacy
applications. If this is not the case nothing can be done as long as the Writer
keeps insisting on integer TWIPS values.
Comment 19 ulf.stroehler 2004-01-27 10:46:04 UTC
*** Issue 23853 has been marked as a duplicate of this issue. ***
Comment 20 ulf.stroehler 2004-06-28 12:03:04 UTC
*** Issue 25553 has been marked as a duplicate of this issue. ***
Comment 21 sforbes 2004-06-28 13:47:23 UTC
changing summery for better results in IZ searches
Comment 22 400guy 2010-10-12 23:36:00 UTC
Maybe I have seen the result of this issue, but in an extreme case
that misled me for quite some time about the actual characters in the
document.  (Short version: look at second line in attachment f3b.png
at about 300% or 400% of natural size.)  I am suggesting that you
consider adding some warning to help other users not waste time the
same way I did.  On the other hand, ...

(*) the result is sensitive to my exact text, font, and spacing, and

(*) perhaps I am unusual in caring so much about one punctuation mark,
    and

(*) it is only my use of a user-defined style which led me to look for
    an esoteric way for a colon to be deleted before I noticed the
    glyph positioning.


One thing that solves my problem is hdu's suggestion (2004-01-06) to
turn on UsePrinterMetricForFormatting, and that is what my proposed
warning message should say to do.  Alas, I cannot suggest how to
recognize when the the warning is appropriate.  Perhaps my situation
is too unusual to be worth attention.


I write "*maybe* the result of this issue" because I get different
visible results depending on whether the OOo window is maximimized or
not.  I do not recognize any of the discussion so far as referencing
the state of the OOo window.


Anyway, here is the long version of my plaint, with screenshots taken
before I followed hdu's suggestion ...


I am running a non-product build of DEV300_m88, but I have also seen
this behaviour from (forked) OOo 2.4.1 as delivered with Ubuntu Hardy
(8.04).  The on-screen rendering of the text is visibly different
depending on whether the OOo window is maximized or not, so let me add
that I running the gnome desktop and my screen size is 1280 by 1024
pixels.  What else, I wonder, might be relevant?  Please let me know
what I can do to clarify the situation.

Please open the (soon-to-be) attached file f3.odt.  It has two
paragraphs with the same text; the first paragraph is just a reminder,
and the second will--I hope--show the difficulty.  If necessary,
maximize the OOo window using the icon at the right end of the title
bar.  Observe (attachment coming soon: f3a.png) that the display is
scaled to 100%, and the scope resolution operator in the second
paragraph clearly shows two colons.

Unmaximize the window using the icon at the right end of the title bar
of the window.  Observe (attachment coming soon: f3b.png) that the
display is still scaled to 100%, but the first colon of the scope
resolution operator in the second paragraph has been reduced to a
couple of small warts on the preceding letter.

Use View > Zoom > Variable to set the display scaling to 75%.  Observe
(attachment coming soon: f3c.png) that the first colon of the scope
resolution operator in the second paragraph is again clearly visible.
Comment 23 400guy 2010-10-12 23:38:08 UTC
Created attachment 72026 [details]
example document
Comment 24 400guy 2010-10-12 23:39:07 UTC
Created attachment 72027 [details]
two colons clearly visible
Comment 25 400guy 2010-10-12 23:39:48 UTC
Created attachment 72028 [details]
first colon obscured
Comment 26 400guy 2010-10-12 23:40:26 UTC
Created attachment 72029 [details]
two colons visible again
Comment 27 Marcus 2017-05-20 11:24:14 UTC
Reset assigne to the default "issues@openoffice.apache.org".
Comment 28 Marcus 2017-05-20 11:25:38 UTC
Reset assigne to the default "issues@openoffice.apache.org".