Bug 174147 - unable to display rendered fonts (indic) properly for some complex base fonts.
Summary: unable to display rendered fonts (indic) properly for some complex base fonts.
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: Indic
TreeView+ depends on / blocked
 
Reported: 2005-11-25 05:30 UTC by Lawrence Lim
Modified: 2014-03-26 00:52 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-12-01 08:50:22 UTC
Type: ---
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
OpenOffice.org 58663 0 None None None Never

Description Lawrence Lim 2005-11-25 05:30:50 UTC
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 05:30:50 UTC
Created attachment 121472 [details]
sample test case containing text from 5 indic locale

Comment 2 Lawrence Lim 2005-11-25 05:31:46 UTC
Created attachment 121473 [details]
sceenshot comparing the output in gedit and openoffice

Comment 3 Caolan McNamara 2005-11-25 08:33:02 UTC
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 23:20:50 UTC
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 23:21:35 UTC
Created attachment 121525 [details]
screenshot taken with oowriter started in ja locale

Comment 6 Caolan McNamara 2005-11-29 08:15:28 UTC
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 09:10:19 UTC
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.