Dear Neil,
In current Scintilla, the character set determines the font and
thus the visual representation of the bytes being drawn. The character
set can be different for each style. My main use for this feature was
to use Japanese fonts only for text that could be Japanese while
drawing styles that were always ASCII text (such as keywords) using a
better looking latin-only font.
SciTE only allows one character set at a time but other editors
may, for example, have displayed different 8 bit character sets (such
as 8859-1 and KOI-8) within one document. If anyone is using this
feature, you'd better speak up or it may disappear.
Is current "charset" feature only valid for "keyword", or entire document?
And I think I needn't the multiple charset feature in one document.
I need only the charset-specify ability for whole document.
I'd like to know if there is any performance impact from the two
MultiByteToWideChar calls. On Unicode based versions it shouldn't be
noticeable (although the OS is supposed to be a little clever here)
but on Windows 9x these strings will often have to be converted
straight back to 8 bit strings. European language Windows 9x users may
not like paying a performance price for a feature that doesn't benefit
them and people using 9x are often on older slower machines.
How about the following solution?
This will avoid the extra permance impact and 8bit string impact.
But it will be very helpful for 16bit strings, including but not-limited
asian fonts.
if(IsNT() || nCodePage==0){
::ExtTextOut(hdc, rc.left, ybase, ETO_OPAQUE, &rcw, s,
Platform::Minimum(len, maxLenText), NULL);
} else {
// Support asian string display in 9x English
wchar_t tbuf[MAX_US_LEN];
int wStrSize=MultiByteToWideChar(nCodePage, 0, s, -1, NULL, 0);
MultiByteToWideChar(nCodePage, 0, s, -1, tbuf, wStrSize);
::ExtTextOutW(hdc, rc.left, ybase, ETO_OPAQUE, &rcw, tbuf,
wStrSize, NULL);
}
I'm wondering if you have the language support packs that were
produced for Internet Explorer or Office installed? My recollection
was that that was one of the things you had to do to work with
Japanese on Windows 95.
Yes, I have updated 98SE English to IE6 SP1 first with CJK display and
input support.
I have tested other editors too.
Both Win32pad (base richedit) and EmEditor can display the CJK file
correctly.
As I think, this feature is important for Scintilla.
> 1. The cursor move is incorrect, sometimes jump two Chinese words (four
> bytes);
> 2. The text cannot be selected.
> 3. When selecting, the string will be refreshed and changed.
This is under the control of Platform::DBCSCharLength, which calls
IsDBCSLeadByteEx so possibly needs a different call.
No, I tried DBCSCharLength() but seems not to work.
And I think current implementation is fine.
The question still exist.
Is there any other relevant clues?
> 5. How to get the codepage in SurfaceImpl class?
During set up of a surface, SetDBCSMode is called with the code
page. As code page is not used in existing Surface code, it is
ignored. If it is needed then it could be stored as a member of
SurfaceImpl.
Yes, I do.
> If possible, I may post the updated PlatWin.cxx file.
Put it on a web site or create a bug on the SourceForge tracker and
attach the file.
I will create a bug tracker and post the file soon.
Jeffrey Ren
_________________________________________________________________
免费下载 MSN Explorer: http://explorer.msn.com/lccn/
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
