Subject: some minor postscript fixes
From: F J Franklin (F.J.Franklin@sheffield.ac.uk)
Date: Sun Oct 29 2000 - 05:43:44 CST
Dear All,
Despite the odieresis on my screen, the postscript printout insisted on a
degree-sign (RemapGlyphsDefault), so I thought that was a good reason to
stop watching from the side-lines and try to Fix The Bug, so 16 hours later
I have traced it to xap_EncodingManager and discovered a few more (mostly
trivial) on the way.
I would be happy to create a patch, but unfortunately I have never created
a patch before so I would be grateful if someone could give me (or point me
towards) a tutorial...
Also, I should probably wait until the CJK stuff is committed?
Frank
<fjf@alinameridon.com>
Affected files:
abi/src/af/xap/unix/xap_UnixPSGenerate.cpp
abi/src/af/gr/xp/gr_Graphics.cpp
abi/src/af/xap/unix/xap_UnixFont.cpp
abi/src/af/xap/xp/xap_EncodingManager.cpp
=========================================================================
abi/src/af/xap/unix/xap_UnixPSGenerate.cpp
attitude in xap_UnixPSGenerate to line-length limit (or is that just an EPS
limit?) seems a little schizophrenic. Anyway:
(1) UT_Bool ps_Generate::writeByte(UT_Byte byte)
UT_Bool ps_Generate::writeBytes(UT_Byte * pBytes, UT_uint32 length)
add conversion to PS escape sequence \ddd (i.e., octal) for characters
in range 127 <= c < 256, return UT_FALSE above this although
UT_uint32 PS_Graphics::measureUnRemappedChar(const UT_UCSChar c)
returns null-width for chars outside this range anyway...
(Is this a good thing?)
(2) UT_Bool ps_Generate::formatComment(const char * szCommentName,
const char **argv, int argc)
UT_Bool ps_Generate::formatComment(const char * szCommentName,
const UT_Vector * pVec)
were skipping arguments at `%%+' line-wraps
=========================================================================
abi/src/af/gr/xp/gr_Graphics.cpp
(1) UT_UCSChar GR_Graphics::remapGlyph(const UT_UCSChar actual_,
UT_Bool noMatterWhat)
out-of-order null-check of m_pApp
l.110 UT_UCSChar actual = m_pApp->getEncodingManager()->try_UToNative(actual_);
l.159 if (!m_pApp)
=========================================================================
abi/src/af/xap/unix/xap_UnixFont.cpp
(1) const FontMappingTable std_enc[] = {
add "mu" = 0x00B5
correct spelling of "Ocircumflex"
correct spelling of "Idieresis"
?? I thought "trademark" was ^{\bf TM} (to use TeX syntax); in this
context "trademark" may just be the same as "registered" = 0x00AE
if "Scaron" == "germandbls", then
?? "scaron" may just be the same as "Scaron" = 0x00DF
?? "zcaron"
?? "Zcaron"
(2) ABIFontInfo * XAP_UnixFont::getMetricsData(void)
When constructing the m_uniWidths (character widths) array:
if (XAP_EncodingManager::instance->try_nativeToU(0xa1)==0xa1)
{
/* it's iso8859-1 or cp1252 encoding - glyphs in font are in wrong
order - we have to map them by name.
*/
[...]
}
else
{
/* it's non-latin1 encoding - we have to assume that order of
glyphs in font is correct.
*/
[...]
}
Fonts such as Nimbus Roman No9 L Regular (AbiSuite/fonts/n021003l.*)
require the first of these methods (i.e., it's iso8859-1 or cp1252
encoding) but the second is being called.
The problem is with the zero (or whatever) returned from
static UT_UCSChar try_CToU(UT_UCSChar c,iconv_t iconv_handle)
Question: Rather than doing either/or, would it not be safer to do
both (i.e., non-latin1 followed by iso8859-1/cp1252)?
=========================================================================
abi/src/af/xap/xp/xap_EncodingManager.cpp
(1) static UT_UCSChar try_CToU(UT_UCSChar c,iconv_t iconv_handle)
Very confused types & casting (though that's not to blame...)
size_t donecnt = iconv(
[...]
uval = (b1<<8) | b2;
assumes that donecnt == 2; replacing the latter with
if (donecnt == 2) uval = (b1<<8) | b2; else uval = b1;
works for me - unfortunately I know very little about the ways of
iconv (), so is this valid?
This archive was generated by hypermail 2b25 : Sun Oct 29 2000 - 05:43:48 CST