Bug 174147 - unable to display rendered fonts (indic) properly for some complex base fonts.
unable to display rendered fonts (indic) properly for some complex base fonts.
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Caolan McNamara
: i18n
Depends On:
Blocks: Indic
  Show dependency treegraph
 
Reported: 2005-11-25 00:30 EST by Lawrence Lim
Modified: 2014-03-25 20:52 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-01 03:50:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
sample test case containing text from 5 indic locale (4.22 KB, text/plain)
2005-11-25 00:30 EST, Lawrence Lim
no flags Details
sceenshot comparing the output in gedit and openoffice (171.68 KB, image/png)
2005-11-25 00:31 EST, Lawrence Lim
no flags Details
openoffice.org-*-2.0.1-0.141.1.2 (150.96 KB, image/png)
2005-11-25 03:33 EST, Caolan McNamara
no flags Details
screenshot taken with oowriter started in ja locale (165.30 KB, image/png)
2005-11-27 18:21 EST, Lawrence Lim
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
OpenOffice.org 58663 None None None Never

  None (edit)
Description Lawrence Lim 2005-11-25 00:30:50 EST
Description of problem:
Thought I open a new bug as the previous Bug 157816,  was for FC4. 
When tried to copy and paste indic text from gedit to oowriter, the information
does not get display properly

Version-Release number of selected component (if applicable):
openoffice.org-core-2.0.1-0.139.1.2
openoffice.org-impress-2.0.1-0.139.1.2
openoffice.org-graphicfilter-2.0.1-0.139.1.2
openoffice.org-draw-2.0.1-0.139.1.2
openoffice.org-writer-2.0.1-0.139.1.2
openoffice.org-math-2.0.1-0.139.1.2
openoffice.org-xsltfilter-2.0.1-0.139.1.2
openoffice.org-calc-2.0.1-0.139.1.2


How reproducible:
Always

Steps to Reproduce:
1.LANG=ja_JP.UTF-8 oowriter
2.copy and paste the sample test case into oowriter
3.
  
Actual results:
see screenshot

Expected results:
same output as gedit

Additional info:
Comment 1 Lawrence Lim 2005-11-25 00:30:50 EST
Created attachment 121472 [details]
sample test case containing text from 5 indic locale
Comment 2 Lawrence Lim 2005-11-25 00:31:46 EST
Created attachment 121473 [details]
sceenshot comparing the output in gedit and openoffice
Comment 3 Caolan McNamara 2005-11-25 03:33:02 EST
Created attachment 121479 [details]
openoffice.org-*-2.0.1-0.141.1.2

odd, looks good for me
Comment 4 Lawrence Lim 2005-11-27 18:20:50 EST
Re: Comment #3

Upgraded to openoffice.org-*-2.0.1-0.141.1.2, I can reproduce your screenshot in
en_US locale. So you are right that it affects only certain locale. :)

For Comment #2, the locale used was bn_IN locale. The next scrrenshot to be
attached is from ja_JP locale, works better but I think composed characters are
not rendered properly.

Comment 5 Lawrence Lim 2005-11-27 18:21:35 EST
Created attachment 121525 [details]
screenshot taken with oowriter started in ja locale
Comment 6 Caolan McNamara 2005-11-29 03:15:28 EST
This is actually more subtle than I thought, depends on the base selected font.
If its a font that passes FT_IS_SFNT( maFaceFT ) one layout engine is used,
otherwise another. In one mode the missing glyphs are inserted in logical order,
in another visual order. So for e.g. the default Japanese font from the ja
locale the ordering is not in logical ordering, so on the glyphs being
substituted the combining doesn't take place, while for e.g. Luxi Mono the
glyphs are in logical order, and so the combining for fallback glyphs does take
place. Fix checked in.
Comment 7 Lawrence Lim 2005-12-19 04:10:19 EST
Verified with openoffice.org-core-2.0.1-145.3.2, font fallback is great now. 

Note You need to log in before you can comment on or make changes to this bug.