Issue 18285

I've noticed this too, with OOo 1.1 RC2 on Linux.

Me,too.  Only regular font -- no italic.

Bitstream Vera Sans and Bitstream Vera Sans Mono, though, work fine.

Confirmed

Reassigned to US.

No italic outline available, thus italic style can not be applied.
Excerpt from fonts.dir ("cat OOo_1.1rc3/share/fonts/truetype/fonts.dir
| grep -i vera"):
VeraMoBd.ttf -misc-Bitstream Vera Sans
Mono-bold-r-normal-utf8-0-0-0-0-m-0-iso10646-1
VeraMoBI.ttf -misc-Bitstream Vera Sans
Mono-bold-i-normal-utf8-0-0-0-0-m-0-iso10646-1
VeraBd.ttf -misc-Bitstream Vera
Sans-bold-r-normal-utf8-0-0-0-0-p-0-iso10646-1
VeraMoIt.ttf -misc-Bitstream Vera Sans
Mono-normal-i-normal-utf8-0-0-0-0-m-0-iso10646-1
VeraMono.ttf -misc-Bitstream Vera Sans
Mono-normal-r-normal-utf8-0-0-0-0-m-0-iso10646-1
VeraSeBd.ttf -misc-Bitstream Vera
Serif-bold-r-normal-utf8-0-0-0-0-p-0-iso10646-1
VeraIt.ttf -misc-Bitstream Vera
Sans-normal-i-normal-utf8-0-0-0-0-p-0-iso10646-1
VeraSe.ttf -misc-Bitstream Vera
Serif-normal-r-normal-utf8-0-0-0-0-p-0-iso10646-1
Vera.ttf -misc-Bitstream Vera
Sans-normal-r-normal-utf8-0-0-0-0-p-0-iso10646-1
VeraBI.ttf -misc-Bitstream Vera
Sans-bold-i-normal-utf8-0-0-0-0-p-0-iso10646-1


*** This issue has been marked as a duplicate of 17352 ***

closing dupe.

that's not a duplicate as it concerns the display; i don't think we
have an issue for that yet, so i'll reopen the issue

pl->hdu: it was only a matter of time :-)

*** Issue 18392 has been marked as a duplicate of this issue. ***

Displaying fonts that don't exist by faking them is not implemented yet on our 
platform builds. Italic is relatively easy, bold is more difficult. It is on the TODO list. 

Further data:

* The problem shows up on OpenOffice.org 1.1.0 and 1.1.1 on Linux (Fedora Core 1
as updated, and Mandrake 10.0 Community, respectively). It also shows up when
you export to PDF (either version), so that an italicised word shows up in the
PDF as roman (non-italicised).

* I opened a document created on Linux (OpenOffice.Org 1.1.0) on Windows
(OpenOffice.Org 1.1.0, W98). The word appeared italicised. However, when I
exported it to PDF on the Windows box, it was not italicised.

* Looking at "Additional comments from us Tue Aug 19 06:23:07 -0700 2003": I ran
the following command line:

find /usr/X11R6/lib/X11/fonts/ /usr/lib/X11/fonts/ -iname fonts.dir -type f |
xargs grep -i bitstream | grep -i ital

and got nothing.

Similarly for:

find /usr/X11R6/lib/X11/fonts/ /usr/lib/X11/fonts/ -iname fonts.dir -type f |
xargs grep -i '\-i\-' | grep vera

It looks like the only workaround for users is to select some other font in
one's default style.

regarding comments from pl, I exetended the summary.

according to the announcement on releases
(http://www.openoffice.org/servlets/ReadMsg?list=releases&msgNo=7503) this issue
will be re-targeted to OOo Later.

Adding myself to cc list.

please reconsider the target.
(ms_interoperability keyword because documents will look differently on
non-windows operating systems)

*** Issue 38355 has been marked as a duplicate of this issue. ***

*** Issue 38355 has been marked as a duplicate of this issue. ***

Forwarded form i38355:

This issue is fixed by one Chinese in Taiwan years ago, but his/her patches were
never passed into OOo's CVS server. I can't understand that because this feature
is quite important to Chinese users of OOo on Linux, and almost every Chinese
derivatives of OOo added this patch.

Chinese users need this feature and there's already a patch for it.

You can find the screenshots after that patch at
http://firefly.idv.tw/setfont-xft/screenshots/OOo-4styles.png and those patches
for OOo at http://firefly.idv.tw/setfont-xft/patches/openoffice/ . 

It was said that this feature will be ok in OOo 2.0, but I didn't see it yet,
quite disappointedly. :(

I didn't want to blame OOo's developers for not searching patches for bugs, I'm
a developer of OOo too. I think OOo's developers or even communities perhaps
could have a better way to communicate with its users, especially who can't
communicate in English freely. (firefly doesn't know much of English, but
perhaps pplwong of zh.openoffice.org could do some help of translation.)

I know that firefly provided that patches years ago, and I know that pplwong,
lead of zh.openoffice.org, also communicated with OOo's developers about this
bug, but perhaps due to certain issues of process or language obstacles, this
patches are still there, out of OOo's CVS tree. Personally I'm quite frustrated
with this kind phenomenon, not for you or other developers of course.

I just feel that it's necessary and beneficial for OOo community to execute more
activly and effectivly, and I feel there's a clear distance between OOo
community and its eastern users. I'm eager to make them closer because I'm a
Chinese, a Chinese developer & user of OOo.

If my earlier phrases hurted anyone, I'd like say sorry here. I really just want
to make OOo better.

add glu to cc list.

firefly's email address is firefly@firefly.idv.tw 

add drbyte to cc

*** Issue 39095 has been marked as a duplicate of this issue. ***

*** Issue 39095 has been marked as a duplicate of this issue. ***

Add hli in cc list .

*** Issue 42883 has been marked as a duplicate of this issue. ***

*** Issue 46944 has been marked as a duplicate of this issue. ***

*** Issue 49485 has been marked as a duplicate of this issue. ***

*** Issue 49485 has been marked as a duplicate of this issue. ***

It's not an enhancement, it's a defect as far as the formula editor is concerned,
since the mathematical variables default font is "Bitstream Vera Serif, Italic".
Bitstream Vera Serif is also OOo Writer's default font. Since it's provided with
very poor Unicode characters, and can't be italicised, I suggest another font,
such as Lucida Sans, to be chosen by default and provided with a full Unicode
set of characters.

umr5174: Bitstream Vera is *not* the default font for math. It is *not* the
default fonts for regular documents.
You seem to be using a modified version of OOo, not the official one. File a bug
against your distribution/whoever created the OOo you're using.

*** Issue 50222 has been marked as a duplicate of this issue. ***

remove glu from cc list.

*** Issue 46846 has been marked as a duplicate of this issue. ***

Hi,
This issue really needs to be fixed if possible, there are many many users
crying out for this ( especially CJK )
There are two parts to the problem, printing and display, printing has been
sorted. For the display part as somebody mentioned before there were patches
hanging around in the wild for OOo1.2/1.3. I took a look at those and also the
latest freetype2 code. Freetype2 has experimental routines for bold and italic
emulation. I've created patch which I will attach to demonstrate.

So, some things about the patch, it depends on creating dummy fonts in the
fontmanager that pretend to be bold or italic versions of fonts that don't
support those attributes. Anyway the FreetypeServerFont class that gets created
as a result of the dummy font knows its lying about its attributes and when
requested to provide a bitmap will do the appropriate transform to provide
emulated bold or italic font. Anyway I really don't think this is the way to go,
the reason being this approach ( providing dummy fonts ) breaks the detection of
fake bold/italic on the printing side of things for obvious reasons ( the font
now lies and says it is bold or italic ) I guess the right way to go would be
for the drawing/font handling layer to detect that the font doesn't handle the
requested attributes ( bold/italic ) and just perform/request the transformation
on the glyph bitmap. Lack of knowledge about vcl and lack of time prevent me
from exploring this further. 
So now we have the two parts of the puzzle working, the visulization and the
printing, they just don't work together. I hope that these patches are useful to
someone to be able to stitch the two parts together. ( also am attaching hacky
patch to make psprinting to work with previous patch, pdf printing doesn't work
but the same hackery is possible, I just don't have time )

Created attachment 29048 [details]
stuff to kick start display of emulated bold/italic

Created attachment 29049 [details]
bad hacky thing to re-enable artificial bold/italic for ps printing

ok forgot to mention, the transformation routines to emulate bold/italic have
been psuedo back-ported from latest freetype2 head so there really shouldn't be
any jca type issues, should there?

cc' myself

set issue type patch

Some comment on this issue:

The GNOME HK developers actually created a LiveCD which solves the artificial
oblique and embolden issue with the particular patches Firefly has created (see
the comment from glu above):

http://gnomedesktop.org/node/2196/36229

Speaking of the upstream developers, with the following version artifiical
emboldening of CJK font is finally available for general Linux system:

freetype 2.1.10 (released in June 2005)
fontconfig 2.3.2 (released in April 2005)
libXft 2.1.7 (released in April 2005)

If you use Nvu or Mozilla Composer, artificial oblique has been working on Linux
for years already; now artificial emboldening is finally working with the latest
version of the above packages (freetype, with the new autofit hinter, is the
last piece to make the puzzle fit together).

In my understanding, OpenOffice.org does not use fontconfig, but rely on its own
font handling system. However it uses freetype, which means technically speaking
the visual part OpenOffice.org should be able to achieve both artificial oblique
and embolden now as far as the display algorithm (freetype) is concerned.

However, I do not understand vcl or OpenOffice.org code enough to comment on how
this could be implemented. I was told that Ubuntu 5.10 will have artificial
embolden working out of the box (for KOffice, AbiWord and other suites which use
fontconfig will have no problem with CJK embolden thus). So OpenOffice.org could
be the last app in the desktop Linux arena to implement this feature.

Importance

This is definitely an important issue and should not be ignored by OO.o developers.
Almost all other mainly used programs under Linux have fixed this problem.

I've noticed this too

I think it's very important for CJK users

This patch is very important for Tawian, China , Japan and Korea.
Our desktop linux need it~~~~

Given the number of votes and voices underlining the importance of the issue I
would like to raise the priority. Please reconsider the target milestone.

npower:

As far as OpenOffice.org 2.0 is concerned, the printing part is already solved.

So the only problem we need to deal with is the visual appearance of virtual style. 

I am talking to Firefly who created the patches for Chinese build of OpenOffice
mentioned at http://zh.openoffice.org/addons.html ,if he's okay with it, I'll
upload his patch targetting 2.0 (1.9.m130) for review tomorrow. Just a few
things need to clear up.

i think this patch can make OOo a better office software 
for everyone. not just China and Taiwan.
 

->zero0w

If you are in contact with this guy then could you ask him to sign the JCA (
that would be extreemly helpful ). Patches from an author that hasn't done so
will not be accepted afaik. As for review, really someone from sun ( or project
lead for this project gsl etc. ) should ideally be involved I guess to help push
it forward. Also a cws needs to be created etc etc. if a JCA is forthcoming I
might be able to help with cws bits.

We need fix this issue soon

So bad no italic

Created attachment 30159 [details]
openoffice-1.9.m130-vcl-virtualstyles-20050919.patch

Attachment#30159 [details] is the patch made by Firefly. As I'm not familiar with way OOo 
rendering characters, I'm wondering about why we couldn't just mapping 
corresponding feature into freetype, if freetype exported the correspoding 
symbol?

Created attachment 30170 [details]
Patch from Mr. Firefly with English comment added to the code, please use UTF-8 encoding to see it.

np->fundawang,zero0w
Thats great, thanks for sourcing the patch, hopefully we can get some progress
with this. I asked before and if either of you are in contact with this guy
could you see what the situation is regarding him signing the JCA, without that
I can't see this patch making it into the codebase which would be a major major
pity. Please if you have any contact with this guy can you find out if he will
sign the jca if has problems with that or whatever.

->npower
Due to unknown reason, Firefly's website has down for maintenance?? We'll 
contact him later. FYI, I've been contacting ooo-build, at least we could get a 
working release before getting it into OOo.

Created attachment 30175 [details]
Screenshot of the Embedded Bitmap glyph vs Normal Vector glyph in TTF, a longer explanation will follow as it takes some time to write all about it.

->fundawang
Great, thanks, hopefully he will be willing to do the jca stuff, meanwhile for
ooo-build the same will apply afaik.
->mh would it be possible for someone from the sun=>vcl team to review this
patch in the hope that a jca is forthcoming, would help expedite things assuming
jca et al.is all in order. Assuming we get a positive respone from mr.firefly I
will create a cws next week.

Ok, this is a small patch comparing to Firefly's previous numerous patches for
OOo 1.1.x. So I think this is reasonable, and actually practical enough to ask
for a reviewer now. Somebody has compiled OOo 2.0.0 with this patch and it is
working okay.

But first, on the JCA license stuff.

-> npower: I have talked to Mr. Firefly on MSN, and he said he's okay with the
JCA agreement. With the permission of his employer he will sign it to allow his
patches to go upstream if it is to be accepted. So I think it is the right time
to ask for a reviewer on this patch. If you can help him on the cws matter it
will be great. 

About the patch:

Please bare with me over the long explanation of this patch. I am contemplating
to add this explanation as comment in the patch itself, but I suppose an open
explanation here is essential.

1. Scope of influence:

This patch will affect Linux, Mac OSX X11 version users of OpenOffice.org
(although OOo 2.0 is under overhaul for Mac OSX). I am not sure about the
Solaris version, because the apply of this patch depends on the version of
freetype OpenOffice.org is using. Is OOo Solaris version using freetype or STSF
(http://stsf.sourceforge.net/) to render screen font in OOo? I am not sure.

2. Patch dependence: this patch depends on freetype 2.1.10

In June 2005, freetype 2.1.10 was released. This was the first official version
to display artificial bold style for true type font under Linux (see more from
my previous comment). The effect of this patch would not be complete if freetype
is not upgraded to this version accordingly - so somebody who works on
integrating freetype with OpenOffice.org Linux version should pay notice to it.

3. To fully understand this patch you have to understand a bit more about font
technology.

Embedded Bitmap:

In late 2004/early 2005, Mr. Firefly has released a new Chinese font called AR
PL New Sung (refer as 'New Sung') under open source license:
http://www.study-area.org/apt/firefly-font/fireflysung-1.3.0.tar.gz

Before New Sung was released, many Chinese Linux users would simply grab the
MingLiu / Simsun font from Windows and use it under Linux, since normal CJK font
is simply too blurry and unclear under Linux. With attachment 30175 [details], you can see
that the New Sung font offers significantly sharper glyph when comparing to
normal CJK font like AR PL Ming2tiL Big5.

So how can this be done? Basically New Sung is now comprised of two sets of
fonts: the original Vector glyph from AR PL Ming2tiL, and the newly added
Embedded Bitmap font for point 11-16. There will be no difference in printing
output, but when displaying on screen, font glyph with size 11,12,13,14,15,16
will be replaced by the sharper Bitmap font embedded. 

As a result, the new patch created by Firefly will need to take this into
account because Bitmap font cannot be italicized (and hence needs to revert back
to vector when italicized). Embedded bitmap is also why MingLiu/Simsun were
preferred by Chinese Linux users despite possible licensing agreement issues
(which could mean legal problems). The New Sung font has officially removed any
legal risk. Hence embedded bitmap deserves the same attention as other normal
TTF should have. It should be noted that OpenOffice.org 1.x also recognizes
embedded bitmap glyph internally.

Okay, this is long enough in one post, I'll try to start explaining what the
patch does in the next comment.

Continued from my previous comment.....


Let me state what this patch does as far as I can understand and after I've
communicated with the patch author. Wherever Firefly has written comment in
Chinese in the patch, I have added a corresponding English comment as possible
(attachment 30159 [details]). I didn't remove his Chinese comment as it is his patch, but
also because if he needed to look at and modify it again, the original comment
will be readily accessible to him.

The patch actually does three things in one shot, two of which relevant to this
bug, they are:
(i) Enable virtual bold / italic style
(ii) Address Embedded Bitmap issue in virtual bold / italic style

And the additional feature is:
(iii) Specific optimization to CJK font by increasing the darkness (gamma) of
the font face when display on screen, particularly to CJK and Thailand font with
point size < 20. This will improve the blurry glyph so that they will be clearer
and much more comfortable to our eyes. Only CJK and Thai fonts are
targetted/affected.

The specific optimization to CJK font could be a bit tricky, and can actually be
splited as a separate patch if the module/bug owner feels uneasy about it.


------------------------------------------------------

In the order suggested in the patch, here is what the patch sets out to do:
IMPORTANT NOTICE: Item 4 & 5 are what I consider as MUST_DO to fix this bug. 

1. Define the GammaInit function

The GammaInit function is defined here as a reference scale for the gamma value
(darkness) of a font. So that when there is a need to increase the darkness
(gamma value) of a font (see item 2), there is no need to re-define the gamma
value again as a reference function already exists. The only thing to do is to
pass the value of gamma_table[x] (see item 6).

2. Search fonts with code page 874, 932, 936, 949, 950, 1361. 

Target these fonts with Gamma enhancement by passing the argument 'mbUseGamma =
true', which will call the Autohint function in freetype.

The code page represents their corresponding country code as documented in the
patch:

+#define TT_CODEPAGE_RANGE_874    (1L << 16) /* Thai */
+#define TT_CODEPAGE_RANGE_932    (1L << 17) /* JIS/Japan */
+#define TT_CODEPAGE_RANGE_936    (1L << 18) /* Chinese: Simplified */
+#define TT_CODEPAGE_RANGE_949    (1L << 19) /* Korean Wansung */
+#define TT_CODEPAGE_RANGE_950    (1L << 20) /* Chinese: Traditional */
+#define TT_CODEPAGE_RANGE_1361   (1L << 21) /* Korean Johab */

In essence, fonts with these country codes will have CJK optimization turned on;
the optimization will increase the Gamma value (darkness) applicable to the
font, so that they will be more clear and less blurry when shown on the screen
(See also item 6 below).

3. If BYTECODE_INTERPRETER is not defined, hinting is still enabled 

Basically, there are two ways to do font hinting in freetype:

a) Bytecode interpreter (which is not enabled by commercial Linux distro to
avoid Apple's patent issue) 
b) freetype's internal autohinter 

In essence, this is to tell OpenOffice.org to use hinting even when Bytecode
interpreter is disabled.

Firefly suggested it is his personal preference rather than a needed
requirement, so it is open to suggestions.

-------------------------------------------------------------

Item 4 & 5 are a bit confusing, but I'll try to explain it as simple as
possible. They are the core fixes of this patch relevant to the bug.

4. Enable virtual italic style

This is to enable virtual italic style when the italic font file of a typeface
is not detected.

But, as I have written in my previous comment, Embedded Bitmap font _cannot_ be
italicized. 

As a result embedded bitmap needs to revert back to vector first, 
hence there are two possible paths for enabling virtual style:

4a) TTF w/ no embedded bitmap (eg. Bitstream Vera Serif, AR PL Mingti2L Big5) :
== Regular vector font -> Enable italic style in OOo -> Italic vector style 

4b) TTF w/ embedded bitmap (eg. AR PL New Sung, Microsoft MingLiu) :
== Regular Embedded bitmap font -> Enable italic style in OOo -> Revert back to
vector font -> Italic vector style


As you can see, a separate path is needed to support virtual italic style for
embedded bitmap.

However, you will see in item 5 that virtual bold style for bitmap is handled
_differently_.

Reviewer(s), please take notice of this.


5. Enable virtual bold style

When the bold font file of a typeface is not detected, virtual bold style is
enabled:
Workflow suggested in the patch:

5a) TTF w/ no embedded bitmap (eg. AR PL Mingti2L Big5) :
== Regular vector font -> Enable bold style in OOo -> Bold vector style

5b) TTF w/ embedded bitmap (eg. AR PL New Sung, Microsoft MingLiu) :
== Regular Embedded bitmap font -> Enable bold style -> Bold *Bitmap* style

OK, here is the difference: Embedded Bitmap _can_ be emboldened. 

Hence the path for processing Embedded bitmap to display virtual bold style is
to write a separate algorithm to display Bold *Bitmap* style. There is _no_ need
to revert back to vector font in this case.


In case you are wondering, for bold AND italic style, the path is to revert back
to vector font first as item 4 suggested.

---------------------------------------------------------------

6. If the font size is < 20, then increasing the gamma (darkness) of the font face.

In simple word, CJKT font will become darker for font size < 20.
This will be _very_ helpful to the Linux users from these countries. Other fonts
are not affected.


Alright, I think this comment is long enough to be digested all at once. :)

Item 4b) actually has some relationship with item 6, but I'll let you guys take
a peek at the code first.  =)

-> npower, 

If you can help on getting a review for this patch, we really appreciate it. As
soon as Firefly gets back to me on the JCA signature, I think we can start to
get this patch moving.

Then OpenOffice.org will rock again :-) .

Hey, KOffice already solves this problem so the OOo developers shouldn't be far
behind =P .

I use this patch : openoffice-1.9.m130-vcl-virtualstyle-20050919.patch
to rebuild my OOo2
that make my OOo looks perfect!
fonts italics and bold face can show italics and bold 
see screenshot here
http://swyear.no-ip.org/resserver.php?blogId=1&resource=ooo2-firefly.png

I use this patch : openoffice-1.9.m130-vcl-virtualstyle-20050919.patch
to rebuild my OOo2
that make my OOo looks perfect!
fonts without italics and bold face can show italics and bold 
see screenshot here
http://swyear.no-ip.org/resserver.php?blogId=1&resource=ooo2-firefly.png

-> zero0w, fundawang

Hi,
IF either/both of you could provide a document(s) with examples of CJK text (
bold, italic & bold-italic) for fonts 
 
a) TTF without embedded bitmap
b) TTF with embedded bitmap
c) something that shows the fontsize < 20pt ( gamma ) 
for testing I'd be grateful, I can of course add non-cjk examples for same, but
I think it would be nice to have some decent examples. Thanks..

-> zero0w, fundawang

Hi,
IF either/both of you could provide a document(s) with examples of CJK text (
bold, italic & bold-italic) for fonts 
 
a) TTF without embedded bitmap
b) TTF with embedded bitmap
c) something that shows the fontsize < 20pt ( gamma ) 
for testing I'd be grateful, I can of course add non-cjk examples for same, but
I think it would be nice to have some decent examples. Thanks..

up,

I hope OO can support bold/italic cjk-font native.:)

Thanks a lot for the nice patch and for the english translations of the
comments. The CWS "fakebold" was created for this issue.

The patch is expected to work very well from a stability standpoint. There are
some minor issues QA should take into consideration when testing the CWS:
- for fonts that cover a lot of the unicode range the "gamma enhancing" is
always turned on, so for these fonts also non-CJK glyphs are affected. If this
is no problem we should consider to turn it on for all fonts. If it is a problem
we should just use the gamma-boost for CJK unicodes.
- the bigger the font/zoom gets the less the artificial emboldening is visible
- the feature #95556# "no hinting for antialiased CJK glyphs" gets disabled
- does the synthetic italic look ok for rotated glyphs, e.g. arabic digits in a
vertical portion?

In the patch there was a small problem with the GlyphCache hashing. If
accidentally the hashes between the original and the synthetic styles matched
the wrong font was displayed.

->hdu
Thats great news that its being taken care of, I had just created a cws for this
but am happy the "experts" are looking at it. One thing, looking at eis, I don't
see the cws so I presume its not marked public, could you do so?

Since my computer motherboard was damaged I was offline for a week.
Ok, let's get back at this bug:

Re: npower

I installed Ubuntu 5.10 which came with OpenOffice.org 1.9-129, and I can create
a sample file you've suggested. However, you still need to have the "AR PL New
Sung" font installed to see its effect.

AR PL New Sung can be found here:
http://www.study-area.org/apt/firefly-font/fireflysung-1.3.0.tar.gz

It should be noted that, unfortunately, Ubuntu 5.10 chose to bundle freetype
2.1.7, while openSUSE has bundled freetype 2.1.10. So I'll have to compile
freetype 2.1.10 & libXft 2.1.7 on Ubuntu again :(.

Re: hdu

Thank you very much for reviewing this patch. 
Let me see if I understand you right on the following issues:

>Thanks a lot for the nice patch and for the english translations
>of the comments. The CWS "fakebold" was created for this issue.

Should it be called "fakestyle" instead? Because in the Linux X11 version,
"fakeitalic" also needs to be emulated besides "fakebold".

> The patch is expected to work very well from a stability standpoint. 
> There are some minor issues QA should take into consideration when
> testing the CWS:

> for fonts that cover a lot of the unicode range the "gamma enhancing" 
> is always turned on, so for these fonts also non-CJK glyphs are affected. 

This is true. Should somebody come up with a "universal font" that covers every
codepoint someday, gamma enhancement over this "universal font" will have the
inadvertent drawback on darkening non-CJK glyphs as well. It should be noted
that most CJK fonts also contain alphanumeric characters (English and numbers)
as well; BUT, they carry an appearance in consistent with the typeface such that
gamma enhancement over these alphanumeric characters is actually a good thing -
because it is the _typeface_ (not the characters) that benefits from it. 

Now if somebody is weird enough to mix typefaces, for instance, to transfer the
alphanumeric glyphs from "Bitstream Vera Sans" and put them into "AR PL Mingti2L
Big5", then the resultant font would cause the concern you mentioned. Otherwise,
I don't think it's a serious issue at this point.

> If this is no problem we should consider to turn it on for all fonts.
> If it is a problem we should just use the gamma-boost for CJK unicodes.

Actually I think most English fonts under Linux have their separate Bold font
file; so they probably won't be affected. For users of other languages, I
personally cannot tell if they would benefit from gamma-boost. But I am guessing
it would be so because I rarely see any font that's too dark under Linux; only
too blurry in most cases.

> the bigger the font/zoom gets the less the artificial emboldening 
> is visible

Are you suggesting we should turn on Gamma for font > 20 pt size too?
It seems to me OOo on Windows also exhibits similar behavior.

> does the synthetic italic look ok for rotated glyphs, 
> e.g. arabic digits in a vertical portion?

Need to test it, we'll go back at this point later.

> In the patch there was a small problem with the GlyphCache hashing. 
> If accidentally the hashes between the original and the synthetic
> styles matched the wrong font was displayed.

I'll ask Firefly to see if he can find a fix for it.

-zero0w

>> If this is no problem we should consider to turn it on for all fonts.
>> If it is a problem we should just use the gamma-boost for CJK unicodes.

> Actually I think most English fonts under Linux have their separate Bold 
> font file; so they probably won't be affected. For users of other languages,
> I personally cannot tell if they would benefit from gamma-boost. But I am
> guessing it would be so because I rarely see any font that's too dark under
> Linux; only too blurry in most cases.

Sorry, I wasn't thinking clear when I wrote the comment above.

Actually what I wanted to say is, if a typeface _has_ its separate Bold font
file, gamma enhancement should _not_ be turned on for them. Because the font
designer has already taken extra step to make sure the bold style 'looks right'
by creating an explicit bold font file. 

In most CJK font, the number of characters/glyphs are well over 10,000 and it
does not make sense to create any additional file just to implement bold or
italic style for the reason of memory & labor required.

As a result, I think I should correct myself and reiterate that we should only
use gamma-boost on CJK fonts for now. In addition, most English fonts look good
and solid in OpenOffice.org under Linux. There's minimal desire in targetting
them for gamma enhancement. 

Hence turning on gamma-boost indiscriminately for all fonts is not really a good
idea, especially for typeface which already has its separate bold font file.

Confirmed

HDU->US: Please check and verify in CWS fakebold. The issues mentioned above and
below are not very important compared to having the feature...

> I'll ask Firefly to see if he can find a fix for it.

No worries, I already applied the fix.

> Actually I think most English fonts under Linux have their separate
> Bold font file; so they probably won't be affected.

There are a plenty of non-CJK fonts with nothing more than regular style.

> Should it be called "fakestyle" instead?

Good idea, but the CWS tools cannot rename a CWS yet.

Re: hdu

>>> In the patch there was a small problem with the GlyphCache hashing. 
>>> If accidentally the hashes between the original and the synthetic
>>> styles matched the wrong font was displayed.

>> I'll ask Firefly to see if he can find a fix for it.

> No worries, I already applied the fix.

Actually I have talked to Firefly, and he said the code on GlyphCache is
actually correct. The following part is taken from his patch code:

<Quote of the code>

@@ -89,6 +89,10 @@ size_t GlyphCache::IFSD_Hash::operator()
     nHash   += rFontSelData.mnHeight;
     nHash   += rFontSelData.mnOrientation;
     nHash   += rFontSelData.mbVertical;

And the following code are added by Firefly:

+    // Add by Firefly(firefly@firefly.idv.tw)
+    nHash   += rFontSelData.meItalic;
+    nHash   += rFontSelData.meWeight;
+    //---------------------------------------
     return nHash;

</Quote of the code>

The new GlyphCache data 'rFontSelData.meItalic' and 'rFontSelData.meWeight' are
added for emulating virtual italic and virtual bold style. The hashes between
the original and the synthetic styles should differ by these two new hash
elements. Are you suggesting the problem related to this part of code? Or are
you referring to a different issue?

>> Actually I think most English fonts under Linux have their separate
>> Bold font file; so they probably won't be affected.

> There are a plenty of non-CJK fonts with nothing more than regular style.

Sure, but this is a different issue. 

Virtual bold style and virtual italic style (item 4 & 5) already take care of
that. That is, gamma boost != virtual bold/italic style. It's a different feature.

Gamma-boost further darkens the font in question _regardless_ of any style (that
is, it will boost all styles) for size < 20 pt.

There is certain subjective element here, I agree. But turning on gamma-boost
for all fonts indiscriminately will have the adverse effect of making certain
fonts look worse. Without gamma boost, virtual style still works: it's just that
those CJK font in questions do not look great in regular / virtual italic stylic
with size < 20pt because they _are_ blurry. 

IMHO, gamma-boost should only be used for fonts which look blurry when
antialiasing (AA) is turned on under Linux. I believe virtual style is a
required feature, but gamma-boost is more like an optimization so that the font
looks even better for the target (CJK) audience. If you feel uneasy about it, I
believe gamma-boost could be splited as a separate patch and then decide on
which font to target later. 

Nevertheless, the general consensus in Chinese Linux community is this patch
works great for them. I think you can add the code for targetting other language
regions later should demand arises.

>> does the synthetic italic look ok for rotated glyphs, 
>> e.g. arabic digits in a vertical portion?

> Need to test it, we'll go back at this point later.

It works okay in 90 degree or 270 degree rotation.

Created attachment 30615 [details]
Sample document created for testing the effect of virtual style patch, as requested by npower

-> npower

> IF either/both of you could provide a document(s) with examples of CJK text 
> (bold, italic & bold-italic) for fonts 
 
> a) TTF without embedded bitmap
> b) TTF with embedded bitmap
> c) something that shows the fontsize < 20pt ( gamma ) 
> for testing I'd be grateful, I can of course add non-cjk examples for same,
> but I think it would be nice to have some decent examples. Thanks..

I have uploaded the preliminary sample document as attachment
"Bitmap_Gamma_test-0.1.odt". It is the standard OpenDocument format for
OpenOffice.org 2.0. The document is pretty self-explanatory. If you have any
further questions or suggestions please reply here or send me an e-mail (see the
document) so I can improve or help to accommodate your (or QA's) effort in
fixing this bug. Thanks.

->zero0w, thanks for creating that test document ( very nice indeed! :-) ), well
I hope this will make 2.0.1 assuming testing etc goes ok. I tried it out and...
looks great for me, I'm sure hdu and the sun engineers will have no problems
with this and it'll finally make it in. :-)

some comments:
+    if (mbUseGamma)
+	mnLoadFlags |= FT_LOAD_FORCE_AUTOHINT;
I think it's not good idea to force autohinting here and is better that user have 
opportunity to turn it on or not since we already have SAL_AUTOHINTING_PRIORITY.
 Maybe some user don't like autohint at all.

> some comments:
> +    if (mbUseGamma)
> +	mnLoadFlags |= FT_LOAD_FORCE_AUTOHINT;
> I think it's not good idea to force autohinting here and is better that user
> have opportunity to turn it on or not since we already have 
> SAL_AUTOHINTING_PRIORITY.

I am not familiar with SAL_AUTOHINTING_PRIORITY, what is this about?

SAL_AUTOHINTING_PRIORITY is a environment variable that you can enable/disable
autohinting.

More patches are here:
http://opendesktop.org.tw/patches/OO.o-2.x/2.0.0/firefly-ooo-2.0-patches.tar.gz

The tarball are sets of patches. If anyone want, I could upload it one by one.

Ok, folks. I have some good news.

Mr. Firefly has filled and signed the JCA agreement and faxing it back to Sun,
under the Printed Name "Deng Jia Min". I think the folks at Sun can verify his
identity thru the e-mail address, which was used in the comment in his patch
uploaded here. 

As a result, may I suggest, after his JCA is verified, that a target milestone
version is set for merging this patch - providing most technical issue is
solved? This is a must-have usability feature for most CJK users, and will
benefit English and other users for handling regular-only font as well.

Re: sunmoon1997

> SAL_AUTOHINTING_PRIORITY is a environment variable that you can 
> enable/disable

Is this an environment variable set in the GUI menu of OpenOffice.org, or just
in the command line? Or is this a compile option?

I am not sure, but can the patch be modified to check for the value of
SAL_AUTOHINTING_PRIORITY first before forcing Autohint on the targetted font
(and targetted font only) ?

Since the Gamma enhancement previously discussed would alleviate some of the
unpleasant effect of Autohint, I am inclined to use this option because of the
result seen in the CJK font involved, such as this screenshot mentioned by
swyear earlier:

http://swyear.no-ip.org/resserver.php?blogId=1&resource=ooo2-firefly.png

Re: fundawang

> The tarball are sets of patches. If anyone want, I could upload it one by one.

Let us keep each patch separate and file a bug report of its own.

I have read some of the description and it looks like some of the new patches
are too CJK-centric (for example, putting CJK font name before English in the
font selection menu) and might not fit the generic interest of all
OpenOffice.org user base. 

However, it's fortunate that many of these new patches are very small ones, and
filing new bugs for each of them and seeking review should be easy. The small
patches would make it easy to read and understand. If I have time I'll get the
comment translated to English before trying to get them uploaded with new bug
reports on what they are trying to address, so more on this later. 

But first, we'll want to get this fake style bug fixed because this is simply
one of the biggest letdown which CJK OOo Linux users would want to see fixed as
soon as possible. I can't wait to recommend my friends to try out StarOffice or
OpenOffice.org on Linux once this (visually noticeable) problem is resolved.

(On a side note, Mozilla Firefox 1.5 has managed to address CJK printing thru
CUPS support, so I begin to believe desktop Linux can expect some uptake in Asia
-- that is, if this bug will also be fixed in the near future :) ).

us->wg: as agreed; for you.

setting back fixed.

Re: us, wg

This is very good news indeed that this bug is resolved as fixed, thanks guys!

Can you confirm that it will be fixed in OOo version 2.0.1, or as in a later
version?

IMO, just remove autohinting, because autohinting usually does bad than good and
it depends on fonts and gyphs. For me, it's not acceptable.

fixed target

Created attachment 32065 [details]
screenshot

Reopened. Italic text under Unix does not look so well..

Reassigned.

I am not sure what's wrong with the screenshot.
Can you upload a screenshot of Windows version for comparison?

What is the correct behaviour supposed to be?

With freetype 2.1.2 the meaning of the xy<->yx components in the transformation
matrix were exchanged, so we have to add a version check.

Here is the link to the freetype commit for the incompatible change:
http://savannah.nongnu.org/cgi-bin/viewcvs/freetype/freetype2/src/base/ftoutln.c.diff?r1=1.47&r2=1.48

The new fix handles freetype's version incompatibility.

The new fix also handles freetype's version incompatibility.

Wait, I thought the virtual _bold_ style itself depends on freetype >= 2.1.10
(please see my previous comment). 

Should we require OpenOffice.org 2.0.2 to check for freetype >= 2.1.10 if we
want this bug to be resolved as fixed? 

While supporting freetype 2.1.2 is nice for older system, the virtual bold style
will disappear for that version (or any version prior to 2.1.10) and would not
serve the purpose of completely fixing this bug. 

Wait, I thought the virtual _bold_ style itself depends on freetype >= 2.1.10
(please see my previous comment). 

Should we require OpenOffice.org 2.0.2 to check for freetype >= 2.1.10 if we
want this bug to be resolved as fixed? 

While supporting freetype 2.1.2 is nice for older system, the virtual bold style
will disappear for that version (or any version prior to 2.1.10) and would not
serve the purpose of completely fixing this bug. 

The artificial bold in this patch is not done via freetype.

Verified in CWS.

hdu:

You are right. After checking with Firefly, it seems that his patch does not
need freetype 2.1.10. Only fontconfig 2.3.x depends on the new freetype to
display virtual bold style. My mistake ;) .

Tested in master m149. Closed.

Hi, The italic xy-yx problem still happens 2.2.1rc3 mac-ppc on 10.3.9(I've no
10.4 env).

Reopen or not:
I don't think this important because of...
* panther become older by fall this year.
* upcoming Mac-native (Panther unsupported, users use Neo or upgrade to Leopard!)
Anyway, I reported this here. I'll go Leopard this fall too.

Thanks.

Created attachment 46128 [details]
Italic xy-yx 2.2.1ja MacOSX10.3.9

*** Issue 56707 has been marked as a duplicate of this issue. ***