Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Character spacing / kerning inaccurate and varies|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||ACCEPTED ---||QA Contact:|
|Priority:||P4||CC:||andreas.martens, frank.meies, hdu, issues, sundman, tenger, ulf.stroehler, xslf|
|Issue Type:||ENHANCEMENT||Latest Confirmation in:||---|
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 firstname.lastname@example.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 email@example.com 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, <firstname.lastname@example.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 email@example.com 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 firstname.lastname@example.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 email@example.com 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, <firstname.lastname@example.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 email@example.com 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 firstname.lastname@example.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 email@example.com 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 24 400guy 2010-10-12 23:39:07 UTC
Created attachment 72027 [details] two colons clearly visible
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 "firstname.lastname@example.org".