Mule-ization of Carbon work
- First Post
- Replies
- Stats
-
Go to
- ----- 2024 -----
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2002 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2001 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2000 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1999 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1998 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
Andrew -- I took a look at your code and it should not be difficult to make
the strings work correctly with internationalized text. Basically, you just
need to figure out what encoding of text the external API's expect and then
call the appropriate conversion functions. For example, if the API's expect
UTF-8, then some variation of replacing XSTRING_DATA (string) with
NEW_LISP_STRING_TO_EXTERNAL (string, Qutf8) should do the trick. This
returns a string in alloca() space so there is no need to free it. (The GTK
code doesn't always do this currently but there is a pending patch among my
workspaces to fix this.)
ben
Hi Ben,
No it shouldn't be difficult. The more difficult thing for me right
now is to find the time.
It's of course already done for text drawing and cut-and-paste in
redisplay-carbon.c and select-carbon.c. The coding system used on Mac
OS X is Qcarbon_unicode, defined in intl-carbon.c. The macro
TO_EXTERNAL_FORMAT was used for external encoding (is that OK?).
Some places that need changes are menus, font names, toolbar help text,
and frame titles. Again I don't think this is hard to do. I'll
probably write a function or macro that uses
NEW_LISP_STRING_TO_EXTERNAL to convert Lisp_String to CFStringRef (OS
X's unicode string representation).
Andrew.
On Feb 21, 2005, at 4:22 PM, Ben Wing wrote:
Andrew -- I took a look at your code and it should not be difficult
to
make
the strings work correctly with internationalized text. Basically,
you just
need to figure out what encoding of text the external API's expect and
then
call the appropriate conversion functions. For example, if the API's
expect
UTF-8, then some variation of replacing XSTRING_DATA (string) with
NEW_LISP_STRING_TO_EXTERNAL (string, Qutf8) should do the trick. This
returns a string in alloca() space so there is no need to free it.
(The GTK
code doesn't always do this currently but there is a pending patch
among my
workspaces to fix this.)
ben
It's of course already done for text drawing and cut-and-paste in
redisplay-carbon.c and select-carbon.c. The coding system
used on Mac
OS X is Qcarbon_unicode, defined in intl-carbon.c. The macro
TO_EXTERNAL_FORMAT was used for external encoding (is that OK?).
Yes, that is totally fine.
Some places that need changes are menus, font names, toolbar
help text,
and frame titles. Again I don't think this is hard to do. I'll
probably write a function or macro that uses
NEW_LISP_STRING_TO_EXTERNAL to convert Lisp_String to CFStringRef (OS
X's unicode string representation).
Sounds good. All of the macros end up accomplishing the same thing. The
only difference between NEW_LISP_STRING_TO_EXTERNAL and the ones based on
TO_EXTERNAL_FORMAT is that the former actually return an alloca()ed string
while the latter require a temporary variable. (Originally I wanted
everything to work like the NEW_* macros, but there turned out to be serious
bugs in the GCC of that era on x86 computers with handling alloca() within
function calls -- thankfully they are now fixed. What I do now, and should
have done then had I thought of it, was to insert a check in `configure' for
broken alloca() within function calls and use the portable alloca()
replacement in alloca.c.)
Btw you'd have to write a macro, not a function, because of the use of
alloca().
ben
7003
days inactive
7004
days old
2 comments
2 participants
tags (0)
participants (2)
-
Andrew Choi -
Ben Wing