Bug 154615

Summary: mpage unable to generate multi-lingual ps file
Product: [Fedora] Fedora Reporter: Lawrence Lim <llim>
Component: mpageAssignee: Michal Hlavinka <mhlavink>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: i18n-bugs, tools-bugs
Target Milestone: ---Keywords: FutureFeature, i18n
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-04-15 11:44:41 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
text file containing all 4 CJK locale characters
ps file generated in the zh_TW.UTF-8 locale none

Description Lawrence Lim 2005-04-12 22:03:27 EDT
Description of problem:
Similar to bug 130118, when plain text files to ps file, mapge tries to determine
the charset of the file from the environment variables. and as a result, it
prevent multi-lingual document from converting properly. If the user is in the
zh_TW locale and the text document contains both zh_CN, zh_TW, ja_JP and ko_KR
characters, only zh_TW characters are process and the rest are blank or replaced
by dots.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.cat CJKtest.txt |mpage > test.ps
2.ggv test.ps
Actual results:
Only TC row (zh_TW) got display properly, the rest are blank

Expected results:
Be able to display all the contents in the document

Additional info:
Comment 1 Lawrence Lim 2005-04-12 22:03:27 EDT
Created attachment 113074 [details]
text file containing all 4 CJK locale characters
Comment 2 Lawrence Lim 2005-04-12 22:04:13 EDT
Created attachment 113075 [details]
ps file generated in the zh_TW.UTF-8 locale
Comment 4 Jens Petersen 2005-09-27 07:59:26 EDT
So C, J and K individually are ok?
Comment 5 Lawrence Lim 2005-11-18 00:05:17 EST
Yes, individually they are OK, as long as the locale match the charset.
Comment 7 Hu Zheng 2007-01-31 02:40:07 EST
I have test mpage-2.5.5 with this file, it will determine the code as UTF-8
But unlucky evince can't open that file, maybe it is the font problem.
Comment 8 Akira TAGOH 2007-02-04 21:49:22 EST
FYI, mpage generates PS file that is relying on CID-keyed font (or fonts
emulated by gs) and CMap to pick the glyphs up from the font in PS. and PS
itself allows to mix languages up in one file.
Just supporting this feature may be easy, but an issue would be how to determine
the font for unified ideographs in UTF-8. e.g. for CJK. possible idea would be
to refers current locale and sort out the font priority against it.
Comment 9 Tony Fu 2008-09-09 23:16:20 EDT
requested by Jens Petersen (#27995)
Comment 11 Michal Hlavinka 2014-04-15 11:44:41 EDT
Lets face it, this is not going to happen. It would increase complexity of mpage too much. Anyway, if anyone wants to spend his time and prepare the patch, he's welcome to do so.