To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=92843
Issue #|92843
Summary|Potential flaw for uninitialized value in vcl/source/g
|di/pdfwriter_impl.cxx
Component|gsl
Version|OOO300m2
Platform|All
URL|
OS/Version|All
Status|NEW
Status whiteboard|
Keywords|
Resolution|
Issue type|PATCH
Priority|P3
Subcomponent|code
Assigned to|pl
Reported by|tora
------- Additional comments from [EMAIL PROTECTED] Sun Aug 17 09:11:24 +0000
2008 -------
Phenomenon:
A special character is wrongly drawn as another glyph which appears in the
same line, prior to the special character. See a snapshot file for details.
This phenomenon can be observed with 2.3.1, but cannot be seen with OOO300_m2.
Reproduction:
Prerequisites
- A bugdoc which includes a special character u301C.
- IPA font files version 001.000, which do not have a glyph of u301C.
Steps
1. Open the bugdoc attached.
2. File > Export as PDF.
3. Open it with a PDF viewer.
Results, running on Linux:
Version Result
========== =========
2.3.1 A special character is wrongly drawn as another glyph
which appears in the same line, prior to the special character.
2.4.1 No problem can be observed
since the glyph level fallback system works well.
DEV300_m14 soffice.bin sometimes crashes for SIGSEGV, segment violation
when a similar bugdoc is exported into PDF format.
Probably caused by another reason somewhere else.
It seems that some area in a memory is polluted.
It is said that the set of IPA font files of version 001.000
has some problems that let GhostScript malfunction.
OOO300_m2 No problem can be observed
since the glyph level fallback system seems to work well.
Background:
A special character encoded in Microsoft Codepage 932, Japanese, aka Shift
JIS, has two different counterparts in Unicode for some historical reasons.
Japanese Industrial Standard (JIS) recommends that the character is
equivalent to u301C, WAVE DASH while Microsoft maps the character to uFF5E,
FULLWIDTH TILDE.
For the reasons, UNIX variants offers two mapping tables for iconv to meet
both requirements.
(a) iconv -f SJIS -t UTF-8 maps the character to u301C.
(b) iconv -f CP932 -t UTF-8 maps the character to uFF5E.
u301C: http://www.unicode.org/charts/PDF/U3000.pdf
uFF5E: http://www.unicode.org/charts/PDF/UFF00.pdf
Most Japanese font files have a glyph of uFF5E while a few Japanese font files
include a glyph of u301C since most font files were originally delivered for
Microsoft Windows before Unicode was introduced. From the beginning, the shape
of the special character was same as that of uFF5E, not u301C. After the
Unicode was introduced, JIS published recommendations on what character
defined in JIS could be mapped to what code point in Unicode. Some mappings,
about 10 characters, were mapped to its counterpart in Unicode in a somewhat
doubtful way which differed from existing de-facto standard.
INFORMATION-TECHNOLOGY PROMOTION AGENCY, JAPAN (IPA) released a software
embedding Japanese TrueType font files under a certain license, for free of
charge in 2004. IPA is an independent administrative institution.
The font files were
ipagp.ttf IPAPGothic
ipag.ttf IPAGothic
ipagui.ttf IPAUIGothic
ipamp.ttf IPAPMincho
ipam.ttf IPAMincho
It is said that they have the same geometries as font files available in
Microsoft Windows Japanese.
The set of IPA font files has three versions.
Version Released Download
======= ======== ===================================================
002.03 Feb 2008
http://info.openlab.ipa.go.jp/ipafont/fontdata/IPAfont00203.zip
002.01 Oct 2007
http://info.openlab.ipa.go.jp/ipafont/fontdata/IPAfont00201.zip
001.000 Jul 2004 no longer officially available, but widely spread.
IPA-fonts-001.000.zip is attached in this issue.
The font files of version 001.000 have no glyph of u301C but uFF5E.
The font files of version 002.03 have no glyph of u301C but uFF5E, either;
The 002.03 does not have a glyph data of u301C; it, however, has a pointer
to the glyph of uFF5E for the code point u301C.
Potential Flaw:
See a sample patch attached for details. That can be considered one of the
causes of the phenomenon which is observed with 2.3.1. The glyph level
fallback system in the version 2.3.1 does not work well or has not been
implemented yet, the value of glyph number is expected to be determined
before the method is called, but the value of it is set to zero because the
system fails to find its fallback glyph.
Although the portion of the code has not been modified through OOO300_m2,
the glyph level fallback system seems to have become improved and a
substituted glyph is successfully found before the method is called.
Thus, the problematic phenomenon is coincidentally, intentionally hidden.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
