Your message dated Sun, 21 Jan 2007 21:39:23 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Bug#407842: Characters of several scripts are not displayed
properly
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: libxul0d
Version: 1.8.0.8-1
Browsers using libxul0d, namely GNOME's Epiphany and Galeon, incorrectly
display characters of several obscure scripts. I can't enumerate all
these scripts because I don't know the complete list. However, some
examples are Linear B, Old Italic, Old Persian and Ugaritic. Samples of
these scripts can be found at Wikipedia, for example at
http://en.wikipedia.org/wiki/Linear_B
Instead of displaying the characters, the browsers replace them with
series of four black diamond-shaped symbols with question marks inside
them. These symbols can be selected along with normal text, one symbol
at a time, and can be copied into other applications, where they are
preserved.
In other parts of the GNOME environment, and in non-GNOME GTK+
applications such as Gajim, the aforementioned scripts appear correctly.
For example, if I open a page in Epiphany, I can't see the characters on
the page; but if I then select the "View Source" option, I can see them
correctly in gedit.
The encoding in the web browsers is correctly set to UTF-8. Characters
of some other uncommon scripts, such as Runic, are displayed correctly.
In case of Epiphany, this behavior is regardless of whether or not Pango
rendering is enabled in GConf.
The fonts to render most of the scripts in question are provided by the
ttf-mph-2b-damase package. However there are some other scripts (for
example, the Sumero-Akkadian cuneiform), for which I have no fonts
installed, that are also incorrectly rendered in the browsers as
described above, and correctly rendered (as rectangular blocks with code
points in them) elsewhere.
chpe on #epiphany @ irc.gnome.org has suggested that this might be a
Debian-specific problem with what he called 'native charset converters'
being enabled.
I am running Debian GNU/Linux 4.0 on i686. My kernel is 2.6.18-3-686,
libc6 is 2.3.6.ds1-8, locale is en_US.UTF-8.
Versions of packages on which libxul0d depends:
* libatk1.0-0: 1.12.4-1
* libc6: 2.3.6.ds1-8
* libcairo2: 1.2.4-4
* libfontconfig1: 2.4.1-2
* libgcc1: 1:4.1.1-21
* libglib2.0-0: 2.12.4-2
* libgtk2.0-0: 2.8.20-3
* libjpeg62: 6b-13
* libmozjs0d: 1.8.0.8-1
* libnspr4-0d: 1.8.0.8-1
* libnss3-0d: 1.8.0.8-1
* libpango1.0-0: 1.14.8-4
* libpng12-0: 1.2.15~beta5-1
* libstdc++6: 4.1.1-21
* libx11-6: 2:1.0.3-4
* libxft2: 2.1.8.2-8
* libxinerama1: 1:1.0.1-4.1
* libxt6: 1:1.0.2-2
* libxul-common: 1.8.0.8-1
* libxul0d: 1.8.0.8-1
* zlib1g: 1:1.2.3-13
Versions of other relevant packages:
* epiphany-browser: 2.14.3-4
* galeon: 2.0.2-4
* ttf-mph-2b-damase: 001.000-3
--
Vasiliy Faronov
--- End Message ---
--- Begin Message ---
Version: 1.8.0.9-1
On Sun, Jan 21, 2007 at 10:47:40PM +0300, Vasiliy Faronov <[EMAIL PROTECTED]>
wrote:
> Package: libxul0d
> Version: 1.8.0.8-1
>
> Browsers using libxul0d, namely GNOME's Epiphany and Galeon, incorrectly
> display characters of several obscure scripts. I can't enumerate all
> these scripts because I don't know the complete list. However, some
> examples are Linear B, Old Italic, Old Persian and Ugaritic. Samples of
> these scripts can be found at Wikipedia, for example at
> http://en.wikipedia.org/wiki/Linear_B
>
> Instead of displaying the characters, the browsers replace them with
> series of four black diamond-shaped symbols with question marks inside
> them. These symbols can be selected along with normal text, one symbol
> at a time, and can be copied into other applications, where they are
> preserved.
This has been fixed in version 1.8.0.9-1. This bug was due to internal
use of UCS-2 instead of UTF-16 in the "native uconv" module, and the
scripts you talk about need 2 16-bits word to encode a character, which
was not possible in UCS-2.
Mike
--- End Message ---
