Bug 425976 - GC.drawText() & GC.drawString() - incorrect rendering of ASCII controls (=UNICODE C0 controls)
Summary: GC.drawText() & GC.drawString() - incorrect rendering of ASCII controls (=UNI...
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 4.3   Edit
Hardware: PC Linux-GTK
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-SWT-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2014-01-17 07:58 EST by Andre Saibel CLA
Modified: 2019-09-17 16:10 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andre Saibel CLA 2014-01-17 07:58:46 EST
Some of the ASCII control characters (also defined in UNICODE http://www.unicode.org/charts/PDF/U0000.pdf) are rendered as a block containing the hexadecimal codepoint info (even if there is a 'real' glyph within the used font), for instance the four NFORMATION SEPARATOR controls 'unit separator' \u001F, 'record separator' \u001E, 'group separator' \u001D and 'file separator' \u001C... and maybe some more.

It seems to be special to Linux' SWT implementation, since the same content is shown correctly on Windows platforms and also on Linux with other apllications e.g. browsers.

public void paintControl(PaintEvent pe)
{
     pe.gc.drawText("abc\u001Exyz", 0, 0);
}
Comment 1 Alexander Kurtakov CLA 2016-12-21 19:19:51 EST
As it's working for the real characters, I don't consider this an issue. Can you point to font with such glyphs to be tried?
Comment 2 Andre Saibel CLA 2017-01-09 04:42:00 EST
The actual misbehaviour is that there's a block with a hex number at all – as well the font doesn't contain special glyphs for the control characters (which is common) as it does.
Comment 3 Eric Williams CLA 2019-09-17 16:10:03 EDT
Reproducible on GTK3.24, Fedora 30, and SWT from master as of today.