Issue 64671

Created attachment 35950 [details]
File containing the font

Created attachment 35951 [details]
screenshot showing problem (check out around the @ character)

Reassigned.

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 <OpenOffice.org 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:

lucidasans;albany;arial;helvetica;lucida;geneva;helmet;sansserif;nimbussansl;nimbussans

It's not OpenOffice.org's fault to display it like this it's your font
configuration...

Resolving as "worksforme"

JA: closing

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.

Hmmm.

@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?

I don't have the cairo canvas running.

ok, one for me then.

Confirmed on a temporarily stripped-down kanotix.

set target 3.x

We should fix this for the next release.

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)?

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
   export SAL_DISABLE_FC_SUBST=1
and this seems to workaround the problem. I still don't understand what the interaction of the drawing 
layer primitives with fontconfig might be...

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
^drawinglayer/inc/drawinglayer/primitive2d/textprimitive2d.

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...

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.

ah. darn. 'style:font-pitch="fixed"'. I don't transport that yet, @hdu, any idea
how to encode *that* in Panose? ;)

Gah, looking at font.hxx, there's Set/GetWidthType(), which *might* map to
PanoseProportion (though not exactly), and also evaluated in GetFcSubstitute().

Resetting target as this is not a 3.1 showstopper.

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?

Created attachment 64762 [details]
add support for FontPitch

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
currently...
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

dtardon->aw: VCL specifies three values of FontPitch: PITCH_DONTKNOW,
PITCH_VARIABLE and PITCH_FIXED; I followed the example of mbItalic that
compresses four (ITALIC_NONE, ITALIC_OBLIQUE, ITALIC_NORMAL and ITALIC_DONTKNOW)
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.

reassigned as there is no progress on this issue

Created attachment 65286 [details]
update patch to apply against DEV300_m61

Created attachment 70593 [details]
update patch for 3.3

This patch looks fairly ok, what extra is needed to get this applied ?

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*/

edit: the index should be 3 instead of four for a zero-based panose-1 array

The owners of drawinglayer and canvas should check the patch. It looks good to me.

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?

Applied patch in CWS impress195.

@wg: Please verify.

Verified in CWS.