Re: [Adobe-source-devel] Win32: ui-core fonts and fudges

[Sean P. <sp...@ad...>]

My intention has been that you can assume UTF-8, however, the intention 
is that we have a tokenized string system with runtime lookup for 
translations (we have something similar to what I want in use at 
Adobe... but not in a form that could be open sourced). So the UTF-8 
isn't just UTF-8, it is UTF-8 with markup. In the next couple of months 
I'll be working on a plan file so this will go into that but here is a 
preview:

All strings can be assumed to be UTF-8, however, they may contain XML 
markup (that is, a string is an XML fragment). Normally a string will 
be tagged as being "external", that is, it can be replaced at runtime 
with an appropriate translation:

"<xstr id='cancel'>Cancel</xstr>"

An external string is looked up at runtime from the id attribute and 
context. Context is provided by platform, locale, application, and 
location of use (such as the particular dialog). If no match is found, 
then the text provided directly in the XML is used as a default, 
english, translation. For common terms, the dictionary can be 
pre-seeded with common english terms so this can be abbreviated:

"<xstr id='cancel'/>"

These strings can include other markup, such as replacement points 
(with attributes), platform specific markup (like hot key markup for 
Windows). Every platform does not have to understand all of the markup. 
Prior to use, the string is passed through a function, xstr_to_xxxx() 
[xxxx might vary on usage, such as CFString for Mac]. These functions 
will resolve the markup and return an appropriate string. Because these 
strings are XML, this provides a way to specify UTF-8 code points 
directly in the string as escaped XML. The filters should assume that 
if the string isn't a valid XML fragment, it is simply raw UTF-8 
(however, if it is an invalid XML fragment, it should also issue a 
warning).

Before we go too much further with making the example client code into 
real library code, we should provide at least a rudimentary xstring 
system.

Sean


On Mar 28, 2005, at 9:13 AM, Foster T. Brereton wrote:

> Yes. I'd like to make the standard character encoding inside the ASL 
> to be UTF8. There isn't any internationalization support currently in 
> the application, but UTF8 is the wisest choice for the internal 
> format.
>
> Your UXTHEME work sounds very impressive! I am interested to take a 
> look at it when you think it's ready.
>
> Blessings,
> Foster
>
> ----- Original Message ----- From: "Ralph Thomas" <ra...@gm...>
> To: "Foster T. Brereton" <fbr...@ad...>
> Sent: Friday, March 25, 2005 5:13 PM
> Subject: Re: [Adobe-source-devel] Win32: ui-core fonts and fudges
>
>
>> So is it okay to standardize on UTF-8 in ui-core? By this I mean that
>> we assume that all strings going in and coming out of ui-core are in
>> UTF-8. This is very easy to do on Win32 (with WideCharToMultiByte and
>> friends) and MacOS (CFString supports UTF-8 as an encoding).
>>
>> UTF-8 could easily be put into the Eve/Adam files (although I guess
>> some care would have to be taken to correctly escape "). It has the
>> additional advantage of containing US-ASCII without any special
>> characters (so existing Eve/Adam files won't create illegible GUI).
>>
>> Thanks!
>>  Ralph
>>
>>
>> On Fri, 25 Mar 2005 09:14:50 -0800, Foster T. Brereton
>> <fbr...@ad...> wrote:
>>> Intriguing! Please keep us posted.
>>>
>>> A lot of the code in Win32 is from an older project. If there are 
>>> newer
>>> and better means of managing these UI elements I'm all for it.
>>>
>>> Blessings,
>>> Foster
>>>
>>> On Mar 24, 2005, at 11:07p, Ralph Thomas wrote:
>>>
>>> > Hi all,
>>> >
>>> > I've been reading through the Win32 ui-core code. I have two 
>>> questions:
>>> >
>>> >   1. Why is the font name hard-coded? Shouldn't DEFAULT_GUI_FONT be
>>> > used?
>>> >   2. How does i18n work? It looks like text is always in the 
>>> current
>>> > codepage (i.e.: not UTF-X).
>>> >
>>> > Also, I've been playing with the UXTHEME bits, and am working to
>>> > remove the fudges. I'm planning on doing this in such a way that 
>>> when
>>> > UXTHEME is available (i.e.: on Windows XP and 2003) it will be 
>>> used to
>>> > look up metrics, and when it's not available the values will be
>>> > calculated and fudged with constants. The UXTHEME font bits can 
>>> also
>>> > tell you about baselines inside widgets (I think -- I haven't 
>>> tested
>>> > it yet).
>>> >
>>> > I'm quite sure that the widget metrics can change on the fly. If 
>>> you
>>> > open Control Panel -> Accessibility -> Display Options, and enable
>>> > high-contrast mode then the sizes of various standard widgets 
>>> change.
>>> > Windows does this by sending a WM_THEMECHANGED message to all 
>>> windows
>>> > (and stock widgets know what to do, owner drawn need to capture the
>>> > message).
>>> >
>>> > I'll keep you updated on my UXTHEME research :).
>>> >
>>> > Thanks,
>>> >   Ralph
>>>
>>> --
>>> Foster T. Brereton              <}}}><              Romans 3:21-26
>>> A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
>>> "What 99 percent of programmers need to know is not how to build
>>> components but how to use them." -- Alexander Stepanov
>>>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel