Reported by a free user against txtwrite running on AIX with a PowerPC chip. The txtwrite device is returning all NULLs for the text, this is because pl_decode_glyph always returns a NULL on this setup. Note that on a little-endian machine (eg x86) this *does* work correctly. pl_decode_glyph always returns the (global!!) value of last_char, which is initially set to 0 and altered by pl_tt_encode_char which is called from pl_tt_char_width. pl_tt_char_width is passed a uint 'char_code' which it treats as a gs_char and passes as such to pl_tt_encode_char. On big-endian systems, with ASCII text values, this results in a 0. I believe that txtwrite will probably *not* work correctly even after this is resolved, please re-assign this bug to me when the PCL interpreter is corrected so I can fix that device too.
I fixed the mismatched parameter. Assign it back if there is more for me to do.
The remaining problem is in gdevtxtw.c, there is a typo around line 1885. Currently: } else if (operation & (TEXT_FROM_CHARS | TEXT_FROM_SINGLE_CHAR)) { ch = pte->text.data.bytes[pte->index++]; } else if (operation & (TEXT_FROM_GLYPHS | TEXT_FROM_SINGLE_GLYPH)) { should be: } else if (operation & (TEXT_FROM_CHARS | TEXT_FROM_SINGLE_CHAR)) { ch = pte->text.data.chars[pte->index++]; } else if (operation & (TEXT_FROM_GLYPHS | TEXT_FROM_SINGLE_GLYPH)) {
Yes that's pretty obviously copied from the TEXT_FROM_BYTES case directly above, and an oversight in not changing bytes to chars. I've fixed that in commit 37e1da602cff3378b3d985637dc582f206aa5cd8 but obviously I have no way of testing it.... I've altered the status to 'fixed' in the hope that this, and the fixes Henry did in commit 80dc061ed4717eef205be05e764ac4f1b8c67632, taken together, will solve the problem. Please reopen the bug if it doesn't.
confirmed this works for me on aix 5.3 TL-12