Apache OpenOffice (AOO) Bugzilla – Issue 18285
Bitstream Vera Serif without italic (fake italics and bold for display for regular-only fonts)
Last modified: 2010-12-03 12:36:13 UTC
Hi, the font bistream vera serif seems to have no italic letters (although you can select italic it's stil regular).
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. ***
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. ***
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. ***
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..
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.
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.
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. ***