Bug 174147

Summary: unable to display rendered fonts (indic) properly for some complex base fonts.
Product: [Fedora] Fedora Reporter: Lawrence Lim <llim>
Component: openoffice.orgAssignee: Caolan McNamara <caolanm>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: eng-i18n-bugs, tools-bugs
Target Milestone: ---Keywords: i18n
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-12-01 08:50:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 126002    
Attachments:
Description Flags
sample test case containing text from 5 indic locale
none
sceenshot comparing the output in gedit and openoffice
none
openoffice.org-*-2.0.1-0.141.1.2
none
screenshot taken with oowriter started in ja locale none

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.