Re: FontDlg sample text

[Dmitry Timoshkov]

"Shachar Shemesh"  wrote:
> * Add sample text characters for Symbol, Japanese, Greek, Turkish,
>   Arabic, Baltic, Vietnamese, Russian, East European and Thai codepages.

Why to not add them into resources? That would simplify locale
handling a lot, and make our translators actually notice that
strings as well.

FontDlg sample text

[Shachar Shemesh]

Dmitry Timoshkov wrote:
> "Shachar Shemesh"  wrote:
> > - Add sample text characters for Symbol, Japanese, Greek, Turkish,
> > Arabic, Baltic, Vietnamese, Russian, East European and Thai codepages.
>
> Why to not add them into resources? That would simplify locale
> handling a lot, and make our translators actually notice that
> strings as well.

The main reason is that they are loaded based on encoding, rather than 
language. This has several implications that caused me not to go that route:
1. The mapping between encoding and charcter encoding is not a 
straightforward one. The reverse mapping is even less so.
2. The mapping is based on the selected locale, and does not care about 
the current language.

These two mean that placing the sample text in a resource will only 
server to confuse the issue. The first point is even harder - what if 
you want different sample text for Chinese BIG-5 and the other Chinese 
encoding? Which language should I try to load for centeral Europe? 
French? German? I can only load one.

In short, doing that through resources seems like an unnecessary 
complication to me. Add to that the fact that you still need the mapping 
table, and you get "ain't worth the hassle".

Shachar

FontDlg sample text

[Dmitry Timoshkov]

"Shachar Shemesh"  wrote:
> The main reason is that they are loaded based on encoding, rather than 
> language. This has several implications that caused me not to go that route:
> - The mapping between encoding and charcter encoding is not a
>
> straightforward one. The reverse mapping is even less so.

Well, GetTextCharset() does exactly what you want.
> - The mapping is based on the selected locale, and does not care about
>
> the current language.

The mapping should be based on the font charset, and actually has nothing
to do with current language or locale.
> These two mean that placing the sample text in a resource will only 
> server to confuse the issue. The first point is even harder - what if 
> you want different sample text for Chinese BIG-5 and the other Chinese 
> encoding? Which language should I try to load for centeral Europe? 
> French? German? I can only load one.

Exactly. GetTextCharset() is your friend here. Just have different
strings for different charsets in the resources and load them at
appropriate time.
> In short, doing that through resources seems like an unnecessary 
> complication to me. Add to that the fact that you still need the mapping 
> table, and you get "ain't worth the hassle".

I hope you will reconsider.

Mmsystem API timeGetTime

[Casper Hornstrup]

How can this API be implemented so it does not have to use
ReleaseThunkLock and RestoreThunkLock (at least the Win32
version)?

DWORD WINAPI timeGetTime(void)
{
    /* FIXME: releasing the win16 lock here is a temporary hack (I hope)
     * that lets mciavi.drv run correctly
     */
    DWORD count;
    ReleaseThunkLock(&count);
    RestoreThunkLock(count);
    TIME_MMTimeStart();
    return WINMM_IData->mmSysTimeMS;
}

Mmsystem API timeGetTime

[Eric Pouech]

Casper Hornstrup wrote:
> How can this API be implemented so it does not have to use
> ReleaseThunkLock and RestoreThunkLock (at least the Win32
> version)?
>
> DWORD WINAPI timeGetTime(void)
> {
>     /* FIXME: releasing the win16 lock here is a temporary hack (I hope)
>      * that lets mciavi.drv run correctly
>      */
>     DWORD count;
>     ReleaseThunkLock(&count);
>     RestoreThunkLock(count);
>     TIME_MMTimeStart();
>     return WINMM_IData->mmSysTimeMS;
> }

I see two ways of doing it:
- either use a function pointer to ReleaseThunkLock & RestoreThunkLock 
which will be initialized if mmsystem is loaded (as we do for most of 
the 16 bit functions we need)
- or load by hand these two function with GetProcAddress, and handle the 
case where they are not defined.
I'd vote for the first one.

A+

Mmsystem API timeGetTime

[Casper Hornstrup]

> -----Oprindelig meddelelse-----
> Fra: Eric Pouech [mailto:[e-mail]] 
> Sendt: 30. november 2003 16:39
> Til: Casper Hornstrup
> Cc: [e-mail]
> Emne: Re: Mmsystem API timeGetTime
>
> I see two ways of doing it:
> - either use a function pointer to ReleaseThunkLock &
>
> RestoreThunkLock 
> which will be initialized if mmsystem is loaded (as we do for most of 
> the 16 bit functions we need)
> - or load by hand these two function with GetProcAddress, and
>
> handle the 
> case where they are not defined.
> I'd vote for the first one.

ReleaseThunkLock and RestoreThunkLock need only be called in
mmsystem.dll? How about this patch?

Mmsystem API timeGetTime

[Eric Pouech]

Casper Hornstrup wrote:
> > -----Oprindelig meddelelse-----
> > Fra: Eric Pouech [mailto:[e-mail]] 
> > Sendt: 30. november 2003 16:39
> > Til: Casper Hornstrup
> > Cc: [e-mail]
> > Emne: Re: Mmsystem API timeGetTime
> >
> > I see two ways of doing it:
> > - either use a function pointer to ReleaseThunkLock &
> >
> > RestoreThunkLock 
> > which will be initialized if mmsystem is loaded (as we do for most of 
> > the 16 bit functions we need)
> > - or load by hand these two function with GetProcAddress, and
> >
> > handle the 
> > case where they are not defined.
> > I'd vote for the first one.
>
> ReleaseThunkLock and RestoreThunkLock need only be called in
> mmsystem.dll? How about this patch?

not exactly, they need to be called when 16 bit support has been added 
to winmm, not only when called from 16 bit (we also need it if called 
from 32 bit with 16 bit support loaded).
this patch should take care of it.
A+

FontDlg sample text

[Rein Klazes]

On Sun, 30 Nov 2003 21:48:47 +0800, you wrote:
> > table, and you get "ain't worth the hassle".
>
> I hope you will reconsider.

This discussion did not answer the question that I was thinking of at
your first remark: do these strings depend on the local language?

It would be inclined to think the would depend only on the character
encoding of the font and need no translation (what is the translation of
AaBb?)

Rein.

FontDlg sample text

[Shachar Shemesh]

Dmitry Timoshkov wrote:
> "Shachar Shemesh"  wrote:
> > The main reason is that they are loaded based on encoding, rather than 
> > language. This has several implications that caused me not to go that route:
> > - The mapping between encoding and charcter encoding is not a
> >
> > straightforward one. The reverse mapping is even less so.
>
> Well, GetTextCharset() does exactly what you want.

I seem to have been totally misunderstood, possibly because of the wrong 
use of "locale" instead of "charset" in my previous mail.

The situation is this:
We have a font. This font supports several charsets. (Almost) each 
charset is used by several locales, but that is besides the point. We 
need to know which characters to use as a sample text demonstrating each 
charset. We need some kind of a table. This table does not depend on the 
current locale.

You suggest resource. I say that this seems like the wrong tool for the 
job, as the resource information seems based on locale, and the locale 
does not play a role here. Maybe I misunderstood what you meant.

Please explain:
1. What kind of a resource should I use, in your opinion?
2. How should I select which resource to load, given a specific locale?
3. What is the advantage of this mechanism?
> > These two mean that placing the sample text in a resource will only 
> > server to confuse the issue. The first point is even harder - what if 
> > you want different sample text for Chinese BIG-5 and the other Chinese 
> > encoding? Which language should I try to load for centeral Europe? 
> > French? German? I can only load one.
>
> Exactly. GetTextCharset() is your friend here. Just have different
> strings for different charsets in the resources and load them at
> appropriate time.

You lost me there. How does GetTextCharset help me, in any way? I'll 
just remind you that thing I have given is the charset, and what I'm 
searching for is the text.
> > In short, doing that through resources seems like an unnecessary 
> > complication to me. Add to that the fact that you still need the mapping 
> > table, and you get "ain't worth the hassle".
>
> I hope you will reconsider.

I'll be happy to. Just let's try and understand the implications.

Shachar

FontDlg sample text

[Shachar Shemesh]

Shachar Shemesh wrote:
I can't believe it. I did it again.
> Please explain:
> - What kind of a resource should I use, in your opinion?
> - How should I select which resource to load, given a specific locale?

Make that: "How should I select which resource to load, given a specific 
charset?"
> - What is the advantage of this mechanism?

Shachar

FontDlg sample text

[Dmitry Timoshkov]

"Shachar Shemesh"  wrote:
> > Please explain:
> > - What kind of a resource should I use, in your opinion?

String resources.
> > - How should I select which resource to load, given a specific locale?

Font charsets doesn't depend on the current user locale. So, just create
LANG_NEUTRAL resource with strings for each charset you want and IDs something
like:

#define CHARSET_BASE 1000

STRINGTABLE
{
    ANSI_CHARSET+CHARSET_BASE    "AaBbYyZz"
    DEFAULT_CHARSET+CHARSET_BASE "AaBbYyZz"
    SYMBOL_CHARSET+CHARSET_BASE  "Symbol"
    ...
}

and load them when you need to display sample text:

char sample[256];

hfont = CreateFontIndirectA(...)
SelectObject(hdc, hfont);
charset = GetTextCharset(hdc);
LoadStringW(hinst_comdlg32, CHARSET_BASE + charset, sample, 256);
DrawTextW(hdc, sample);
> Make that: "How should I select which resource to load, given a specific 
> charset?"
> > - What is the advantage of this mechanism?

I mentioned at least one already: make it easily available for translators.

You could always have a look at the traces produced by native comdlg32,
since it uses an approach described above, and learn how it's done there.

FontDlg sample text

[Shachar Shemesh]

Dmitry Timoshkov wrote:
> "Shachar Shemesh"  wrote:
> > > Please explain:
> > > - What kind of a resource should I use, in your opinion?
>
> String resources.
> > > - How should I select which resource to load, given a specific locale?
>
> Font charsets doesn't depend on the current user locale. So, just create
> LANG_NEUTRAL resource with strings for each charset you want and IDs something
> like:
>
> #define CHARSET_BASE 1000
>
> STRINGTABLE
> {
>    ANSI_CHARSET+CHARSET_BASE    "AaBbYyZz"
>    DEFAULT_CHARSET+CHARSET_BASE "AaBbYyZz"
>    SYMBOL_CHARSET+CHARSET_BASE  "Symbol"
>    ...
> }

How do I put Unicode there? I need to put in characters that, by 
definition, are taken from very varied parts of the unicode charset table.

If that problem is *easilly* solveable, I'll glady do the change. Note, 
however, that this is no reason not to commit the patch I sent, as the 
scheme currently used has been in place since February. All the current 
patch did was enhance the sample text for more charsets.

Shachar

FontDlg sample text

[Dmitry Timoshkov]

"Shachar Shemesh"  wrote:
> How do I put Unicode there? I need to put in characters that, by 
> definition, are taken from very varied parts of the unicode charset table.
> If that problem is *easilly* solveable, I'll glady do the change.

Have a look at one of unicode only locale .nls files from dlls/kernel, for
instance dlls/kernel/nls/guj.nls. That should be quite straightforward.
> Note, 
> however, that this is no reason not to commit the patch I sent, as the 
> scheme currently used has been in place since February. All the current 
> patch did was enhance the sample text for more charsets.

Sure. I agree.