Issue 64671 - Verdana font messes up letter spacing in Impress
Summary: Verdana font messes up letter spacing in Impress
Alias: None
Product: Impress
Classification: Application
Component: formatting (show other issues)
Version: OOo 2.0.2
Hardware: All Linux, all
: P2 Trivial (vote)
Target Milestone: 3.4.0
Assignee: wolframgarten
QA Contact: issues@graphics
Depends on:
Blocks: 90439
  Show dependency tree
Reported: 2006-04-23 21:32 UTC by keithcu
Modified: 2017-05-20 10:30 UTC (History)
7 users (show)

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

File containing the font (30.08 KB, application/vnd.sun.xml.impress)
2006-04-23 21:33 UTC, keithcu
no flags Details
screenshot showing problem (check out around the @ character) (78.56 KB, image/png)
2006-04-23 21:34 UTC, keithcu
no flags Details
add support for FontPitch (10.64 KB, patch)
2009-09-15 09:10 UTC, dtardon
no flags Details | Diff
update patch to apply against DEV300_m61 (10.64 KB, patch)
2009-10-10 15:35 UTC, caolanm
no flags Details | Diff
update patch for 3.3 (12.13 KB, patch)
2010-07-13 11:10 UTC, caolanm
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description keithcu 2006-04-23 21:32:59 UTC
I can repro this with a default install of Ubuntu + OpenOffice 2.02.

I got a file which contained vera as the font. The display looks fine in normal
mode, but when I change to slideshow, the spacing is all garbled. Including the
file and a screenshot so you can see what I'm talking about.
Comment 1 keithcu 2006-04-23 21:33:40 UTC
Created attachment 35950 [details]
File containing the font
Comment 2 keithcu 2006-04-23 21:34:49 UTC
Created attachment 35951 [details]
screenshot showing problem (check out around the @ character)
Comment 3 wolframgarten 2006-04-24 07:53:36 UTC
Comment 4 Joost Andrae 2006-04-25 09:50:10 UTC
JA: the font used within that document is "Verdana" and it seems that it's been
replaced with a font with broken font metrics. If you take a look at the font
replacement list in < installation
directory>/share/registry/data/org/openoffice/VCL.xcu the font verdana is
replaced by lucidasans, then by albany, then by arial, ... 

Full replacement list for verdana:


It's not's fault to display it like this it's your font

Resolving as "worksforme"
Comment 5 Joost Andrae 2006-04-25 09:51:19 UTC
JA: closing
Comment 6 keithcu 2006-04-25 10:56:37 UTC
I have discovered that none of the replacement fonts are on my system. What
fonts gets used then?

I have also discovered that normal view printing is using a different font than
slideshow view. Simply pressing F5 changes the fonts on my slide. Is that possible?

Maybe slideshow view has a different codepath for the font it chooses when none
of the font doesn't exist on the computer.

I agree that there could be a font with screwed up metrics, especially as the
same letters seem to screw up on every slide. However, I cranked up Krita and
went through all of the fonts on my computer and couldn't reproduce the problem
with any of them displaying "The Quick Brown Fox Jumps Over The Lazy Dog." It
should show a screwed up "i, r, w, J m o" etc, and I didn't ever see that in its
view as I arrowed down through every font.

Comment 7 thb 2006-06-06 16:27:24 UTC
@keithcu: hm, sounds strange, since basically, slideshow mode and edit mode use
the same font selection scheme. could you tell me whether you've maybe the cairo
canvas running during slideshow (that would mean a checked 'hardware
acceleration' mark in the tools->options->view configuration tabpage)? And if
yes, if the bug persists when that checkmark is turned off?
Comment 8 keithcu 2006-06-06 20:52:26 UTC
I don't have the cairo canvas running.
Comment 9 thb 2006-06-07 10:13:31 UTC
ok, one for me then.
Comment 10 thb 2006-06-07 10:14:33 UTC
Confirmed on a temporarily stripped-down kanotix.
Comment 11 Martin Hollmichel 2008-01-28 02:25:55 UTC
set target 3.x
Comment 12 thb 2008-06-27 10:09:25 UTC
We should fix this for the next release.
Comment 13 thb 2009-01-14 14:39:32 UTC
Now, that's interesting - in checking this doc in a m38, I find edit and
slideshow mode showing the same - both are broken now.

@hdu: any chance you could have a quick look at that, it seems it's related to
metafile rendering (entering edit mode on any of the objects display text
correctly again)?
Comment 14 2009-01-14 16:01:45 UTC
Interesting. AW had an idea with drawing layer primitives caching the font name, which he'll explain soon. 
Speaking of font name and mapping problems I tested with
and this seems to workaround the problem. I still don't understand what the interaction of the drawing 
layer primitives with fontconfig might be...
Comment 15 Armin Le Grand 2009-01-14 16:17:07 UTC
AW: So we have three modes now to distinguish:
(a) Text in edit mode
(b) Text drawn in edit view
(c) Text in Presentation

While (a) is painted by the Outliner using the OutlinerParaObject, (b) is pained
from the primitive processors using the data from TextSimplePortionPrimitive2D.
I think THB could clarify what (c) uses, but i think it's the MetaFile data from
a Paint internally using the primitive processors, too, so it should be the same
effect as looking at (b).

I do not know exactly what (a) uses for painting, e.g. if the VCL Font is hold
in the OutlinerParaObject's ItemSet data, but (b) uses the data provided from
TextSimplePortionPrimitive2D. This includes the DXArray, Locale, FontColor and
FontAttributes. These again use FamilyName, StyleName, Weight and some bolleans
(e.g. Symbol). Have a look at

That data is derived during text decomposition from an outliner running in
callback mode. Data is taken from the VCL Font which was handed over in that
callback mode.

Using that data the renderers construct a new VCL Font. This is where the Font
Matching will hapen. It will get the same data that was derived from Outliner's
callbacks and the handed over VCL Font.

Thus, it should create exactly the same font as used in Outliner at text
decomposition time.

I also found out (maybe relevant) that the outliner's callback mode always gives
a DXArray which is transported using the primitive and used when the renderer
renders the text (using VCL again). The TextSimplePortionPrimitive2D is layouted
to work without DXArray, though, but it's not used since the Outliner always
delivers one. Maybe - when there is a chance to find out that DXArray is not
needed - the text decomposition may create text primitives without DXArray and
this could be better, but i do not know.

It may have more to do with Linux font substitution; at least i have not seen
this problem on Windows yet. Also, the text decomposition and the renderer
paints are both at runtime on the same system (same Fonts available).

HTH for the moment...
Comment 16 thb 2009-01-14 17:13:01 UTC
Changed title, and noting that the common thing between b) and c) is that
OutputDevice state is transported by querying all available information &
sticking that into another outdev later on - which apparently causes at least
one attribute to differ internally.
Comment 17 thb 2009-01-14 17:56:57 UTC
ah. darn. 'style:font-pitch="fixed"'. I don't transport that yet, @hdu, any idea
how to encode *that* in Panose? ;)
Comment 18 thb 2009-01-14 18:01:14 UTC
Gah, looking at font.hxx, there's Set/GetWidthType(), which *might* map to
PanoseProportion (though not exactly), and also evaluated in GetFcSubstitute().
Comment 19 wolframgarten 2009-03-03 10:35:17 UTC
Resetting target as this is not a 3.1 showstopper.
Comment 20 dtardon 2009-09-15 08:43:42 UTC
The following patch adds support for transferring VCL's FontPitch through
DrawingLayer to Canvas. I think adding support for FontWidthType would follow
basically the same path, but some approximation would be required, as there are
9 levels of condensedness/extendedness in VCL as opposed to 4 (+ 1 basic) in Panose.

dtardon->thb: What do you think about the patch?
Comment 21 dtardon 2009-09-15 09:10:09 UTC
Created attachment 64762 [details]
add support for FontPitch
Comment 22 Armin Le Grand 2009-09-15 10:45:02 UTC
AW: Took a look at the patch. Is okay from my POV. Maybe an enum as member would
be more future safe (are there only two modes?), but when a bool will do
I want to mention that the step of transporting this info over the MetaFile
would be obsolete when Slideshow would change to get it's data from primitives
directly, though. Just a remider to change slideshow to primitive usage (please)
which would enable removal of MANY hacks.
OTOH it shows that is was good not to define an UNO API for the LowLevel
primitives from the beginning; there are still new members coming down the drain.
Just my 2c...

+1 from me
Comment 23 dtardon 2009-09-15 11:04:29 UTC
dtardon->aw: VCL specifies three values of FontPitch: PITCH_DONTKNOW,
PITCH_VARIABLE and PITCH_FIXED; I followed the example of mbItalic that
possible values of VCL's FontItalic to two. There would be problem to express
any additional values in panose anyway.

I'm going to look at transporting FontWidthType next.
Comment 24 clippka 2009-09-28 14:37:19 UTC
reassigned as there is no progress on this issue
Comment 25 caolanm 2009-10-10 15:35:13 UTC
Created attachment 65286 [details]
update patch to apply against DEV300_m61
Comment 26 caolanm 2010-07-13 11:10:41 UTC
Created attachment 70593 [details]
update patch for 3.3
Comment 27 caolanm 2010-07-13 11:11:44 UTC
This patch looks fairly ok, what extra is needed to get this applied ?
Comment 28 2010-07-13 11:42:44 UTC
thb asked:
> 'style:font-pitch="fixed"'. I don't transport that yet, @hdu, any idea how to encode *that* in Panose?

Panose[4 /*proportion*/] = 9 /*monospaced*/
Comment 29 2010-07-13 11:44:42 UTC
edit: the index should be 3 instead of four for a zero-based panose-1 array
Comment 30 2010-07-13 11:52:16 UTC
The owners of drawinglayer and canvas should check the patch. It looks good to me.
Comment 31 thb 2010-07-13 14:38:00 UTC
oh dear. @dtardon: sorry for dropping the ball on this, of course, patch is
good, let's fix this asap.

@af/@hdu: any cws your side we could stick this in, please?
Comment 32 groucho266 2010-07-14 14:54:50 UTC
Applied patch in CWS impress195.
Comment 33 groucho266 2011-02-09 08:57:46 UTC
@wg: Please verify.
Comment 34 wolframgarten 2011-02-14 10:24:55 UTC
Verified in CWS.