Apache OpenOffice (AOO) Bugzilla – Issue 107834
sw: at various zoom values the pseudu-bold/italic disappears in writer
Last modified: 2013-08-07 14:44:07 UTC
In sw/source/core/txtnode/fntcache.cxx writer fetches the Metrics of the physical font, and under some circumstances, e.g. in the heuristic of... if ( (nSWidth <= nPWidth) || (nSWidth * 32 <= nOWidth ) ) { // No adjustment, we take the same font for the output // device like for the reference device pOut->SetFont( *pPrtFont ); ... } else { // The metrics give a better result. So we build // a new font for the output device based on the // metrics used at the reference device pScrFont = new Font( aMet ); // mit Abgleich ... } the font used is taken *directly* from the physical metrics of the underlying font. Now the problem is that some fonts e.g. AR PL UMing CN etc don't have bold/italic versions so vcl is faking these properties with freetypes emboldening feature or something else. So the physical metrics do *not* contain the bold/italic settings, so building a font directly on the font metrics looses this information. The outcome is that at some zoom levels bold/italic is lost. e.g. the attached example
Created attachment 66762 [details] example document
The whole affair in writer looks a bit dodgy to me, but putting that aside, attached are two plausible workarounds. Either in sw to retain these properties, or in vcl to mess with the metrics.
Created attachment 66763 [details] hackaround in writer
Created attachment 66764 [details] alternative hackaround in vcl, probably less desirable
I suspect there may be connections here to issue 92859 and issue 88636.
I agree that the patch against SW makes more sense and is safer. Reassigning to the owner of the patch target code in SW. The other platforms Aqua and Win also do artificial bold and italic so I wouldn't be surprised if it is reproducible there too.
As HDU already reviewed the patches and decided that the Writer patch make more sense, I am applying the Writer patch for the next release.
applied Writer patch in cws sw33bf02 - changed file: /sw/source/core/txtnode/fntcache.cxx, change set 75f88a4cc5eb
OD->MRU: Checked in internal installation set of cws sw33bf02 - please verify.
It results that the patch does not work as expected. Deeper investigations are needed together with HDU. Thus, removing the code changes from cws sw33bf02 in order to continue with cws sw33bf02
.
taking over again
od->hdu: Please have a deeper look at this issue and at CMC's patch. It reveals the following: - The given document under Windows at zoom 65% shows that the bold is lost. - The given patch does not fix the defect under Windows. Debugging the patch reveals that under Windows the setting of weight and italic at the font has not effect, because the corresponding font has already set these values. od->cmc: Under which conditions and under which platform do you see that the bold/italic is lost?
forgot to re-assign
Platform is Linux, see https://bugzilla.redhat.com/show_bug.cgi?id=545824 for details. You need a font like "UMing" which doesn't have a bold variant. Write some text in it in writer make it bold, and fiddle with the zoom.
Here is what is happening: An obsolete heuristic (see issue 100611 for details) triggers for some scenarios. Now Writer tries to use a different font and like Caolan already described the attribute bits can get lost during this process. Refreshing them to the attributes original request makes very much sense. Getting rid of the whole if-branch which tries to use a different font than the requested font would make even more sense. This has been so at least since bitmap-fonts and nine-pin printers with builtin-fonts- only got out of fashion. @od: using the uming.ttc helped me to reproduce the problem here. I copied it into your shared folder.
Thx CMC and HDU. Now I reproduced the defect - I needed a newer Linux version. As discussed with HDU I will remove the complete "special" handling from method <SwFntObj::CreateScrFont(..)> - issue 100611. Thus, this patch will be obsolete.
applied patch together with fix for issue 100611 - change set 110a4de18b01
Reassigned to ES
Verified in CWS sw33bf03
closing, seen DEV300_m79