On Thu, 5 Oct 2000, Martin Sevior wrote:
>
> Just some quick questions. Where do I get Russion Fonts? Do I just place
> them in a subdirectory of the Unixfonts directory?
You can get the fonts here:
ftp://ftp.ice.ru/pub/freeware/abiword/AbiWord-fonts-KOI8.tar.bz2
Just unpack them into "fonts" directory - this will create several
subdirectories in it. Everything should work out of the box.
These fonts are in KOI8-R encoding. In order to test them, you'll have to set
$LANG to ru_RU.KOI8-R.
> Also do you have some Russian Abiword documents somewhere for us to test
> your code with?
I've uploaded a set of files (rtfs and docs exported from wordpad and Word2k
and the native .abw) with same content - one sentence with only one russian
word and a hint on how it should like with correct russian fonts (approximated
in latin letters). It's here: http://www.hippo.ru/~hvv/abiword/testdocs-ru.tgz
> I've fixed the patch problem and the patch now compiles and generates a
> workable abiword executable. I'm running RedHat 6.2 with Helix updates.
Nice.
> Until I have Russian fonts I can't do much more testing excpet to try out
> other foreign language spelling files.
>
> One problem I immediately see is that bullet list items show up as "?"
> characters. I don't have any more time today to track this down.
The code that does this is in
GR_Graphics::remapGlyph()
It should be fixed this way (tested):
- const UT_UCSChar actual = m_pApp->getEncodingManager()->UToNative(actual_);
+ UT_UCSChar actual = m_pApp->getEncodingManager()->try_UToNative(actual_);
+ if (!actual)
+ actual = actual_;
This is pseudo-diff for already patched /src/af/gr/xp/gr_Graphics.cpp
Another fix (that fixes competely another problem) is required too - to
xap_UnixFontManager.cpp:XAP_UnixFontManager::_addFont
(so that registry and encoding of xlfd won't be used for decision which
font should replace which).
Here is a real diff for already patched file:
--- xap_UnixFontManager.cpp-old Thu Oct 5 14:38:14 2000
+++ xap_UnixFontManager.cpp Thu Oct 5 14:41:45 2000
@@ -457,7 +457,6 @@
void XAP_UnixFontManager::_addFont(XAP_UnixFont * newfont)
{
// we index fonts by a combined "name" and "style"
- const char* native_encoding =
XAP_EncodingManager::instance->getNativeEncodingName();
const char* fontkey = newfont->getFontKey();
UT_HashEntry* curfont_entry = m_fontHash.findEntry(fontkey);
if (!curfont_entry || !curfont_entry->pData)
@@ -465,43 +464,14 @@
m_fontHash.addEntry(fontkey, NULL, (void *) newfont);
} else {
/*
- we already have the same font but with different encoding.
- Try to figure out which one suits our locale better.
+ since "standard fonts" folder is read first and then
+ current charset-specific subdirectory, it's obvious that
+ the recent version is current charset-specific font,
+ so we replace original font (that is standard)
+ unconditionally.
*/
- XAP_UnixFont* curfont =
static_cast<XAP_UnixFont*>(curfont_entry->pData);
- char curcharset[200];
- char newcharset[200];
- for(int i=0;i<2;++i)
- {
- char* outbuf = i ? newcharset : curcharset;
- XAP_UnixFont* afont = i ? newfont : curfont;
- XAP_UnixFontXLFD lfd(afont->getXLFD());
- if (*lfd.getEncoding()!='*')
-
sprintf(outbuf,"%s-%s",lfd.getRegistry(),lfd.getEncoding());
- else
- strcpy(outbuf,lfd.getRegistry());
- }
- UT_Bool leave_cur = 1;
- if (!UT_stricmp(curcharset,native_encoding))
- leave_cur = 1;
- else if (!UT_stricmp(newcharset,native_encoding))
- leave_cur = 0;
- else if (!UT_stricmp(curcharset,"adobe-fontspecific"))
- leave_cur = 1;
- else if (!UT_stricmp(newcharset,"adobe-fontspecific"))
- leave_cur = 0;
- else
- {
- /* advanced logic could be put here like pattern matching */
- leave_cur = 1;
- }
- UT_DEBUGMSG(("Favouring font '%s' in %s over %s\n",newfont->getName(),
- leave_cur ? curcharset : newcharset, !leave_cur ? curcharset :
newcharset) );
- if (leave_cur)
- delete newfont;
- else {
- delete curfont;
- curfont_entry->pData = (void*)newfont;
- };
+ XAP_UnixFont* curfont =
+static_cast<XAP_UnixFont*>(curfont_entry->pData);
+ delete curfont;
+ curfont_entry->pData = (void*)newfont;
}
}
I've put an updated version of the patch on my site, but these are the only
2 differences between the old one.
> Can you upgrade to the latest version of CVS using Sam's gzipped patches?
> There is a lot of extra work in there already.
It's very hard forme on my slow and breaking link to checkout so much data
from cvs (cvs doesn't allow resuming). I would like to ask for either of the
following:
1) Can someone checkout most recent version from cvs in one directory, tar +
gzip (bzip2) it and allow downloading it?
2) Even more preferable for me:
Get vanilla 0.7.11 sources from abisource.com and extract it in one as for
compiling
Checkout the most recent version of everything from cvs into another
directory and put a gzipped diff between these two directories somewhere.
This approach will minimize the size of things to be downloaded by me.
> In the future can you make a patch against current CVS using Sam's new
> patches against current CVS?
Hmm, sorry I don't understand you. What's in Sam's new patches against
current CVS?
Anyway, when I'll have CVS tree on my disk, I will be able to make patches
against it of course.
> This is an extremely impressive piece of work. I look forward to
> integrating it into the tree. Can Windows programmers download Sam's
> version of Abi and tell Vlad what else needs fixing?
AbiWord is impressive app, so all people should enjoy it. This patch will
increase the number of people enjoying AbiWord.
> Thanks!
>
>
> Martin
>
Best regards,
-Vlad
