Thai diacritical letters printed next to letter, not above



Core Graveyard
Printing: Xprint
15 years ago
9 years ago


(Reporter: Drew Parsons, Assigned: Roland Mainz)


(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)




(3 attachments)



15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030714 Debian/1.4-2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030714 Debian/1.4-2

Thai places symbols above standard letters (I'll call them diacriticals, similar
to the European umlaut or circumflex).  Mozilla (1.4) renders them correctly on
screen, but when the page (e.g. is printed using Xprint,
the diacriticals appear next to the base letter, not above it where they should be.

Note that Bug #127661 is related to similar Thai issues, but not in printing.
I would hazard a guess the same problem affects other complex layout languages
like Arabic, Hebrew or Hindi.

Reproducible: Always

Steps to Reproduce:
1. Go to
2. Print page using Xprint
3. Compare layout of text on printed page to text on screen.

Actual Results:  
Diacritical symbols placed next to the base letter.

Expected Results:  
Diacritical symbols should appear above the base letter.

Comment 1

15 years ago
Can you...
1. ... make a testcase
2. ... attach a sample print job, printing the testcase from [1]

... and finally: Which Xprint server version are you using ?

Comment 2

15 years ago
Here's a snapshot from (without the pictures) and also the
postscript generated from it on my system.

I used mozilla 1.4 and the Ancalagon 0.0.9 test release of Xprint (rpm).  I can
test it again on my proper deb package if you think it might make a difference. 

By the way, the print preview looks fine (same as screen), it's only the
postscript output that goes wrong.

Comment 3

15 years ago
Created attachment 128091 [details]
Test page from

Comment 4

15 years ago
Created attachment 128092 [details]
Gzip'ed Postscript output from test page


15 years ago
Attachment #128092 - Attachment mime type: application/x-tar → application/postscript

Comment 5

14 years ago
Comment on attachment 128092 [details]
Gzip'ed Postscript output from test page

I see the problem in your PostScript output... but I cannot reproduce it on my
side... maybe because all builds I have are build with --enable-ctl ("enable
Complex Text Layout" - which is AFAIK a requirement to render Thai correctly).

So the question is:
Was your build compiled with --enable-ctl or not (see about:buildconfig in
Mozilla) ?
Attachment #128092 - Attachment mime type: application/postscript → application/octet-stream

Comment 6

14 years ago
Swapping Owner <---> QA to get this on my radar...

... and confirming per sample output in attachment 128092 [details] ...
Assignee: katakai → Roland.Mainz
QA Contact: Roland.Mainz → katakai


14 years ago
Attachment #128092 - Attachment description: Postscript output from test page → Gzip'ed Postscript output from test page

Comment 7

14 years ago
Created attachment 128468 [details]
Sample output printing the testcase (attachment 128091 [details]) using Mozilla 2003-07-09-08-trunk_cvs (build with --enable-ctl) and Xprt "ancalagon" 009 prototype (DIN-A4, 300DPI) - seems to print OK

Comment 8

14 years ago
I guess you're right.  about:buildconfig shows:

--prefix=/usr --sysconfdir=/etc --mandir=/usr/share/man
--infodir=/usr/share/info --localstatedir=/var
--with-default-mozilla-five-home=/usr/lib/mozilla --disable-debug
--disable-tests --disable-short-wchar --enable-xprint --enable-strip-libs
--enable-crypto --enable-mathml --enable-oji --enable-extensions=all
--enable-ldap --with-system-zlib --enable-freetype2
--enable-default-toolkit=gtk2 --enable-svg --without-system-mng
--without-system-png --disable-xft 

No --enable-ctl.  I'll bug the maintainer about it.

Comment 9

14 years ago
There is now a Linux/x86 "calendar-enabled" build for Linux/x86 available


13 years ago
Blocks: 65896

Comment 10

13 years ago
Thai diacriticals are placed correctly now (Firefox 1.0, Xprint 0.1.0.alpha1).

The font looks too small, mind you, but that's a different matter (and is
already reported elsewhere I think).
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
WORKSFORME per comment 10
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.