From @skule.ecf.toronto.edu:tee@ecf.toronto.edu Sun Apr 11 23:27:20 1993 Return-Path: <@skule.ecf.toronto.edu:tee@ecf.toronto.edu> From: TEE LUNS To: soft-authors@ifcss.org Subject: HBF suggestions Date: Mon, 12 Apr 1993 00:16:37 -0400 Status: O Hi All, Just leafing through the API section of Draft 0.3, two things came to mind. First is the treatment of error conditions: reporting an error is fairly consistent with the exception of HBF_GetBitmap. For consistency, would anybody object to making it's prototype int HBF_GetBitmap(IN HBF_Handle handle, IN HBF_HzCode hanziCode, OUT HBF_BytePtr bitmap); instead? My other rationale for suggesting this is my concern of where and how long bitmaps are kept. The original prototype suggests that the font library would keep the entire dictionary in memory, but this might not always be desirable. Another approach within the original prototype would be for the library code to keep its own buffers for returning bitmaps in, but then the question is when these buffers get recycled. In the extreme case of there being only one buffer, the lifespan of the returned bitmap being until the next call to HBF_GetBitmap would make sense, but I'm concerned about overlapping bitmap requests - in particular, when one thread (oh, did I mention that I'm writing for OS/2?) of a program may request a bitmap before another thread is done with the one it requested. Returning the bitmap into a secure space provided by the caller seems a better idea. Oh, just for consistency, how about the same idea for HBF_OpenFont? int HBF_OpenFont(IN char *filename, OUT HBF_Handle *handle) Anyway, the other thought WRT error reporting, I'm a little biased toward's OS/2 convention of 0 being the return value for a successful call. This allows different return values for different errors should the caller be interested in what exactly went wrong. Within this proposal, again being a selfish OS/2 programmer , in the cases where there are already established error codes (i.e. operating system return values) would there be any objection to using OS/2's error codes? (I can provide actual values for the spec without much difficulty, but give me a day or so to find them) Luns ~{V#HsJ@~} From mcpong@cs.ust.hk Tue Apr 13 01:11:15 1993 Return-Path: Date: Tue, 13 Apr 93 14:07:44 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) To: soft-authors@ifcss.org Subject: tee's comment on HBF API Status: O > From: TEE LUNS > Subject: HBF suggestions > Date: Mon, 12 Apr 1993 00:16:37 -0400 > > Hi All, > Just leafing through the API section of Draft 0.3, two things came > to mind. First is the treatment of error conditions: reporting an error > is fairly consistent with the exception of HBF_GetBitmap. For consistency, > would anybody object to making it's prototype > > int HBF_GetBitmap(IN HBF_Handle handle, IN HBF_HzCode hanziCode, > OUT HBF_BytePtr bitmap); > > instead? My other rationale for suggesting this is my concern of where > and how long bitmaps are kept. The original prototype suggests that the > font library would keep the entire dictionary in memory, but this might > not always be desirable. Another approach within the original prototype > would be for the library code to keep its own buffers for returning > bitmaps in, but then the question is when these buffers get recycled. Thank you for the comments. The API doesn't specify how to implement. You have suggested 2 approaches. There could be others, e.g., a font server. I would presume a font server or any "clever" implementation will keep a cache of glyph bitmaps. Probably a more precise description of HBF_GetBitmap() should specify that the applicaton should not free the memory (i.e. the bitmap) pointed to by the returned pointer. Thank you for reminding this. Here is my update to include such point: HBF_BytePtr HBF_GetBitmap( IN HBF_Handle handle, IN HBF_HzCode hanziCode ); /* Get the bitmap for the given hanzi code. * * RETURN the pointer to the byte sequence of the bitmap of the hanzi; * or NULL if invalid HBF handle or invalid hanzi code. * +new> * The application must not free the bitmap memory pointed to by +new> * the returned pointer. It is up to the implementation of the API +new> * to determine how to use the memory for the bitmaps. */ /* N.B.: * It is up to the application to show the bitmap properly within * the FONTBOUNDINGBOX, if different from HBF_BITMAP_BOUNDING_BOX. */ /************************************************************/ > In the extreme case of there being only one buffer, the lifespan of the > returned bitmap being until the next call to HBF_GetBitmap would make > sense, but I'm concerned about overlapping bitmap requests - in particular, > when one thread (oh, did I mention that I'm writing for OS/2?) of a program > may request a bitmap before another thread is done with the one it requested. > Returning the bitmap into a secure space provided by the caller seems a > better idea. ^^^^^^^^^^^^^^^^^^^ This is one particular implementation. It's fine; but another implementation may not need to "return the bitmap into a secure space provided by the caller". I suppose a multi-thread application program can still use the original API, as long as it doesn't free the memory -- i.e. multiple read is allowed; "write" (or more precisely "create"/"free") is only done in the API implementation. > Oh, just for consistency, how about the same idea for HBF_OpenFont? > > int HBF_OpenFont(IN char *filename, OUT HBF_Handle *handle) Please see above. c.f. what is specified in draft v0.3: HBF_Handle HBF_OpenFont( IN char * filename ); /* Open and initialize an HBF file. * * RETURN handle for the HBF; * NULL if error. */ /************************************************************/ The API implementation of HBF_CloseFont may not directly free the passed-in handle. The implementation can use some sort of counter to free only when sure, say, in a multi-thread application program. > Anyway, the other thought WRT error reporting, I'm a little biased > toward's OS/2 convention of 0 being the return value for a successful > call. This allows different return values for different errors should the > caller be interested in what exactly went wrong. I agree with this point. But there is a consensus of "keep it simple" for HBF Standard v1.0; and so return 0 or 1 is "sufficient" (for the time being). Also, the convention of returning 1 if in error is due to readablity: if ( ! HBF_CloseFont(...) ) { report error message return or exit or abnormal path } (I recall actually I originally proposed "return 0 if OK"; but I'm convinced to "follow the convention".) If returning 0 means OK, then one would write: if ( HBF_CloseFont(...) ) { <-- doesn't read so well ^^^^^^^^^^^^^^^^^^^^ report error message return or exit or abnormal path } > Within this proposal, again > being a selfish OS/2 programmer , in the cases where there are already > established error codes (i.e. operating system return values) would there > be any objection to using OS/2's error codes? (I can provide actual values > for the spec without much difficulty, but give me a day or so to find them) > > Luns > ~{V#HsJ@~} Let's see if any other supports your arguments. If not, I presume we should keep draft v0.3 as it is, except the update of the API HBF_GetBitmap() as mentioned above (about "mustn't free returned pointer"). mcpong@cs.ust.hk (note new e-address) mcpong@uxmail.ust.hk will still work for some time. From @skule.ecf.toronto.edu:tee@ecf.toronto.edu Tue Apr 13 12:20:56 1993 Return-Path: <@skule.ecf.toronto.edu:tee@ecf.toronto.edu> From: TEE LUNS To: mcpong@cs.ust.hk (Dr. Man-Chi PONG) Subject: Re: tee's comment on HBF API Cc: soft-authors@ifcss.org Date: Tue, 13 Apr 1993 13:17:51 -0400 Status: RO >The API doesn't specify how to implement. You have suggested 2 approaches. >There could be others, e.g., a font server. I would presume a font server >or any "clever" implementation will keep a cache of glyph bitmaps. > >Probably a more precise description of HBF_GetBitmap() should specify that >the applicaton should not free the memory (i.e. the bitmap) pointed to by >the returned pointer. Thank you for reminding this. Well, it's not so much a concern of freeing the memory as it is a matter of not knowing how long the returned pointer still points to the bitmap you think it does. I'm concerned in particular about the following sequence of events Thread 1 Thread 2 HBFmap1 = HBF_GetBitmap(...); [thread does other stuff] HBFmap2=HBF_GetBitmap(...); [do something with HBFmap2] [do something with HBFmap1] There's not really anything to guarantee that thread 2's call to HBF_GetBitmap doesn't trounce the buffer that was returned in setting up HBFmap1; this under the presumption that we aren't working with the 'entire dictionary in memory' approach. The only really safe approach would be to have HBF_GetBitmap allocate the buffer it's returning the bitmap in, and letting the caller free it afterwards, but this gets expensive. Actually, now that I think of it, there is another solution, but it's not too pretty either - the library would have to maintain a seperate set of buffers for each thread. But it'd all boil down to having a copy-out version of HBF_GetBitmap somewhere in the library, and then another (rather ugly) layer to handle return buffers to match the API. I don't really like this approach though as ideally, the code shouldn't care which thread it's running under. >> Oh, just for consistency, how about the same idea for HBF_OpenFont? >> int HBF_OpenFont(IN char *filename, OUT HBF_Handle *handle) > >Please see above. >c.f. what is specified in draft v0.3: > > HBF_Handle HBF_OpenFont( > IN char * filename ); > > /* Open and initialize an HBF file. > * > * RETURN handle for the HBF; > * NULL if error. > */ > /************************************************************/ > >The API implementation of HBF_CloseFont may not directly free the passed-in >handle. The implementation can use some sort of counter to free only when >sure, say, in a multi-thread application program. My concern with HBF_OpenFont isn't so much a multi-threading matter, as it is a matter of being able to report errors with more detail than a 'suceed/fail'. A multithreading program which wants to use the same font from different threads should be smart enough to use the same HBF_Handle, unless it's just by accident that the threads are using the same font (i.e. both could in general point to anything, but the user happens to pick the same one). In this case though, yes it would be nice for the implementation to recognize and share the handle. Returning a new handle does however have the nice side-effect of taking care (although still with restrictions) the problem worrying me with HBF_GetBitmap(). >If returning 0 means OK, then one would write: > > > if ( HBF_CloseFont(...) ) { <-- doesn't read so well > ^^^^^^^^^^^^^^^^^^^^ > report error message > return or exit or abnormal path > } Well, as the point of 0=OK is to allow making use of different nonzero return values, you'd want to keep track of what the return value is. In this case, it'd be int error; if (error=HBF_CloseFont(...) ) { reporterror(error); return or exit etc... } Seems pretty readable to me, with the only problem being that my compiler always warns me about the assignment in test expression. > From ygz@cs.purdue.edu Tue Apr 13 02:07:38 1993 Return-Path: To: mcpong@cs.ust.hk (Dr. Man-Chi PONG) Cc: soft-authors@ifcss.org Subject: Re: tee's comment on HBF API In-Reply-To: Your message of Tue, 13 Apr 1993 14:07:44 +0700. <9304130607.AA13318@cs.ust.hk> Date: Tue, 13 Apr 1993 02:05:30 -0500 From: ygz@cs.purdue.edu (Yongguang Zhang) Status: O In message <9304130607.AA13318@cs.ust.hk> mcpong write > Here is my update to include such point: > > HBF_BytePtr HBF_GetBitmap( > IN HBF_Handle handle, > IN HBF_HzCode hanziCode ); > > /* Get the bitmap for the given hanzi code. > * > * RETURN the pointer to the byte sequence of the bitmap of the hanzi; > * or NULL if invalid HBF handle or invalid hanzi code. > * > +new> * The application must not free the bitmap memory pointed to by > +new> * the returned pointer. It is up to the implementation of the API > +new> * to determine how to use the memory for the bitmaps. > */ > > /* N.B.: > * It is up to the application to show the bitmap properly within > * the FONTBOUNDINGBOX, if different from HBF_BITMAP_BOUNDING_BOX. > */ > /************************************************************/ How about this prototype: int HBF_GetBitmap( IN HBF_Handle handle, IN HBF_HzCode hanziCode, INOUT HBF_BytePtr bitmapBuffer ); where the bitmap is written (copy-out) by API into the space provided by application program (pointed by bitmapBuffer). In this case, it is up to the application programmer to allocate the space, either static, on stack, or dynamic allocated in heap, and guarantee that the space is there when HBF_GetBitmap is called. The API doesn't need to worry about the buffer management. > I suppose a multi-thread application program can still use the original API, > as long as it doesn't free the memory -- i.e. multiple read is allowed; > "write" (or more precisely "create"/"free") is only done in the API > implementation. There will be protential difficulty with multi-threaded API with buffer management. You have to worry much about the code re-entrance stuffs. On the other hand, the copy-out solution may be much cleaner. > Also, the convention of returning 1 if in error is due to readablity: > > if ( ! HBF_CloseFont(...) ) { > report error message > return or exit or abnormal path > } > > (I recall actually I originally proposed "return 0 if OK"; but I'm convinced > to "follow the convention".) > > If returning 0 means OK, then one would write: > > > if ( HBF_CloseFont(...) ) { <-- doesn't read so well > ^^^^^^^^^^^^^^^^^^^^ > report error message > return or exit or abnormal path > } Hmm, for more readable, the code should be: if ( HBF_CloseFont(...) != OK ) { ... } no matter what the macro OK is (0 or 1). --ygz From simpson@math.psu.edu Tue Apr 27 08:57:09 1993 Return-Path: From: Stephen G Simpson Date: Tue, 27 Apr 93 09:50:26 -0400 To: soft-authors@ifcss.org Subject: HBF public announcement? Status: O To the HBF group: In various postings to CCNET etc. I have been mentioning HBF as an "emerging standard" for Chinese bitmap fonts. Consequently I have received a few requests for more information about HBF. Is HBF ready to go public? It would be nice to be able to send people an HBF information file stating the nature and purposes of HBF and where to get technical information such as the HBF 1.0 standard. Or, do you think this is premature? Maybe we don't want to go public until we have a sample API implementation, etc. Your thoughts, please? From ygz@cs.purdue.edu Tue Apr 27 14:25:31 1993 Return-Path: To: soft-authors@ifcss.org Subject: In-Reply-To: Your message of Tue, 27 Apr 1993 09:50:26 -0400. <9304271350.AA12026@boole.math.psu.edu> Date: Tue, 27 Apr 1993 14:18:47 -0500 From: ygz@cs.purdue.edu (Yongguang Zhang) Status: O I am studying the X11 XLFD properties for HBF. I have trouble in finding the right values for the following properties in Chinese fonts. FAMILY_NAME WEIGHT_NAME SLANT SETWIDTH_NAME ADD_STYLE_NAME Here are the definitions and samples for Western fonts. But I don't think they can be well applied for Chinese fonts. ==================== * FAMILY_NAME: FAMILY_NAME is a string that identifies the range or ``family'' of typeface designs that are all variations of one basic typographic style. It is up to the type supplier to supply and maintain a suitable string for this field and font property, to secure the proper legal title to a given name, and to guard against the infringement of other's copyrights or trademarks. FAMILY_NAME may include an indication of design ownership if considered a valid part of the typeface family name. The following are examples of FAMILY_NAME: Helvetica ITC Avant Garde Gothic Times Times Roman Bitstream Amerigo Stone * WEIGHT_NAME: WEIGHT_NAME is a string that identifies the font's typographic weight, that is, the nominal blackness of the font, according to the FOUNDRY's judgment. Examples include: Bold DemiBold Medium * SLANT: SLANT is a code-string that indicates the overall posture of the typeface design used in the font. The encoding is as follows: Code English Translation Description ------- ----------------------- --------------------------- ``R'' Roman Upright design ``I'' Italic Italic design, slanted clockwise from the vertical ``O'' Oblique Obliqued upright design, slanted clockwise from the vertical ``RI'' Reverse Italic Italic design, slanted counterclockwise from the vertical ``RO'' Reverse Oblique Obliqued upright design, slanted counterclockwise from the vertical * SETWIDTH_NAME: SETWIDTH_NAME is a string that gives the font's typographic proportionate width, that is, the nominal width per horizontal unit of the font, according to the FOUNDRY's judgment. The following are examples of SETWIDTH_NAME: Normal Condensed Narrow Double Wide * ADD_STYLE_NAME: ADD_STYLE_NAME is a string that identifies additional typographic style information that is not captured by other fields but is needed to identify the particular font. ADD_STYLE_NAME is not a typeface classification field and is only used for uniqueness. Its use, as such, is not limited to typographic style distinctions. The following are examples of ADD_STYLE_NAME: Serif Sans Serif Informal Decorated ============ The question is, how can we use these fields to represent a Chinese font style? Where to put the the names such such SongTi, FanSongTi, HeiTi, KaiTi, etc? Or, do we need to introduce new properties for Chinese fonts. Also, I wonder if there is any taxonomy definition of "style" for the Chinese typeface. Any comments? --ygz From mcpong@cs.ust.hk Tue Apr 27 20:32:47 1993 Return-Path: Date: Wed, 28 Apr 93 09:27:13 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) To: soft-authors@ifcss.org Subject: X11R5 properties for full HBF Status: O > From: ygz@cs.purdue.edu (Yongguang Zhang) > Date: Tue, 27 Apr 1993 14:18:47 -0500 > > I am studying the X11 XLFD properties for HBF. > I have trouble in finding the right values for the following properties > in Chinese fonts. > > FAMILY_NAME WEIGHT_NAME SLANT SETWIDTH_NAME ADD_STYLE_NAME In the past discussion, we have "agreed" on some of the property values. Some are not discussed; following is my suggestion to all the above. [[ Actually, the example "full HBF" in draft 0.3 has considered these issues. ]] > Here are the definitions and samples for Western fonts. But I don't > think they can be well applied for Chinese fonts. > > ==================== > * FAMILY_NAME: > > FAMILY_NAME is a string that identifies the range or ``family'' of > typeface designs that are all variations of one basic typographic style. > It is up to the type supplier to supply and maintain a suitable string for > this field and font property, to secure the proper legal title to a given > name, and to guard against the infringement of other's copyrights or > trademarks. FAMILY_NAME may include an indication of design ownership > if considered a valid part of the typeface family name. > > The following are examples of FAMILY_NAME: > Helvetica > ITC Avant Garde Gothic > Times > Times Roman > Bitstream Amerigo > Stone FAMILY_NAME value can be one of the five common types kai song fangsong ming (maybe fangsong ~== ming, but we can keep these two names to conform to the original name of the raw bitmap files.) hei (Though "black style" can be interpreted as a kind of "bold" Chinese font, to keep with common practice, we should regard it as a different "style" ("ti" in pinyin).) or any others which are not so common. > * WEIGHT_NAME: > > WEIGHT_NAME is a string that identifies the font's typographic weight, > that is, the nominal blackness of the font, > according to the FOUNDRY's judgment. > > Examples include: Bold DemiBold Medium WEIGHT_NAME value can be "medium" for all kind of Chinese fonts (The "FAMILY_NAME hei" has taken care of bold font.) > * SLANT: > > SLANT is a code-string that indicates the overall posture of the > typeface design used in the font. The encoding is as follows: > > Code English Translation Description > ------- ----------------------- --------------------------- > ``R'' Roman Upright design > ``I'' Italic Italic design, slanted clockwise from > the vertical > ``O'' Oblique Obliqued upright design, slanted clockwise > from the vertical > ``RI'' Reverse Italic Italic design, slanted counterclockwise > from the vertical > ``RO'' Reverse Oblique Obliqued upright design, slanted > counterclockwise from the vertical All the commonly available Chinese bitmap files are "upright design", thus SLANT "r" Any really slanted font can be assigned the proper values as suggested in the description. > * SETWIDTH_NAME: > > SETWIDTH_NAME is a string that gives the font's typographic > proportionate width, that is, the nominal width per horizontal unit of the > font, according to the FOUNDRY's judgment. > > The following are examples of SETWIDTH_NAME: > Normal > Condensed > Narrow > Double Wide SETWIDTH_NAME "normal" Most of the commonly available Chinese bitmap files appear to be "normal" :-) No strange glyph is observed. > * ADD_STYLE_NAME: > > ADD_STYLE_NAME is a string that identifies additional typographic > style information that is not captured by other fields but is needed > to identify the particular font. ADD_STYLE_NAME is not a typeface > classification field and is only used for uniqueness. > Its use, as such, is not limited to typographic style distinctions. > > The following are examples of ADD_STYLE_NAME: > Serif > Sans Serif > Informal > Decorated We have agreed on one example: if the font is encoded in GB, but the glyphs are actually those of traditional hanzi, then use: ADD_STYLE_NAME "fantizi" [[ originally it's ADD_STYLE_NAME "fanti" Now I think to avoid ambiguity, spell "traditional hanzi" in full to become ADD_STYLE_NAME "fantizi" ]] Of course, the inverse case is "jiantizi". The default is that we don't need to mention it; either GB2312-1980 or Big5 suggests the glyphs should be "jiantizi" or "fantizi" already. For unicode, it can be ADD_STYLE_NAME "fantizi" ADD_STYLE_NAME "jiantizi" ADD_STYLE_NAME "fantizi and jiantizi" ^^^ This noise word can be omitted. With this, it reads better to me. Say, a font server wishes to match a font may search for the value ""jiantizi" and/or "fantizi" to find a font which has the desired kind of glyphs. > ============ > > The question is, how can we use these fields to represent a Chinese font > style? Where to put the the names such such SongTi, FanSongTi, HeiTi, > KaiTi, etc? Or, do we need to introduce new properties for Chinese fonts. > > Also, I wonder if there is any taxonomy definition of "style" for > the Chinese typeface. > > Any comments? > > --ygz Summary: I suggest assigning the most commonly used values for such properties for commonly available Chinese fonts (which are what we have now). Ignore the fancy values (at least for the time being). mcpong P.S. ygz has written shell scripts to check the X11R5 properties. He has found some minor errors/inconsistency in draft 0.3. When he releases the shell scripts, I'll releave draft 0.4 which also includes the update on API due to the comments from tee@ecf.toronto.edu Hopefully draft 0.4 would really become the Standard v1.0. From ygz@cs.purdue.edu Wed Apr 28 03:55:20 1993 Return-Path: To: mcpong@cs.ust.hk (Dr. Man-Chi PONG) Cc: soft-authors@ifcss.org Subject: Re: X11R5 properties for full HBF In-Reply-To: Your message of Wed, 28 Apr 1993 09:27:13 +0700. <9304280127.AA06252@cs.ust.hk> Date: Wed, 28 Apr 1993 03:49:17 -0500 From: ygz@cs.purdue.edu (Yongguang Zhang) Status: O Hi, In message <9304280127.AA06252@cs.ust.hk> mcpong@cs.ust.hk writes: > In the past discussion, we have "agreed" on some of the property values. > Some are not discussed; following is my suggestion to all the above. > FAMILY_NAME value > can be one of the five common types > kai > song > fangsong > ming (maybe fangsong ~== ming, but we can keep these two names > to conform to the original name of the raw bitmap files.) > hei (Though "black style" can be interpreted as a kind of "bold" > Chinese font, to keep with common practice, we should > regard it as a different "style" ("ti" in pinyin).) > or any others > which are not so common. I am not ready to buy this. :-) I happen to have an ETEN advertisement brochure (dated dec/92) at hand. It mentioned quite a large variant of fonts, so let's try and see how we can incorporate them in our font properties. For example, the ETen "card" version include the following font "styles": ~{Cw~} ~{?,~} ~{A%~} ~{T2~} ~{:Z~} ~{PP~} For ~{Cw~} ~{T2~} ~{:Z~} , each has the following "weights": ~{5%O_~} ~{O8~} ~{VP~} ~{4V~} The simply character version also supports 3 styles: ~{KN~} ~{Cw~} ~{:Z~}. All these are call "~{M Date: Thu, 29 Apr 93 23:57:11 -0700 From: lee@fritter.stanford.edu (Fung Fung Lee) To: soft-authors@ifcss.org In-Reply-To: Yongguang Zhang's message of Wed, 28 Apr 1993 03:49:17 -0500 Subject: X11R5 properties for full HBF Status: O >Date: Wed, 28 Apr 1993 03:49:17 -0500 >From: ygz@cs.purdue.edu (Yongguang Zhang) > > >Hi, > >In message <9304280127.AA06252@cs.ust.hk> mcpong@cs.ust.hk writes: > >> In the past discussion, we have "agreed" on some of the property values. >> Some are not discussed; following is my suggestion to all the above. Yes, I "agreed". > >> FAMILY_NAME value >> can be one of the five common types >> kai >> song >> fangsong >> ming (maybe fangsong ~== ming, but we can keep these two names >> to conform to the original name of the raw bitmap files.) >> hei (Though "black style" can be interpreted as a kind of "bold" >> Chinese font, to keep with common practice, we should >> regard it as a different "style" ("ti" in pinyin).) >> or any others >> which are not so common.> > Ming and FangSong are two different font families. > >I am not ready to buy this. :-) > >I happen to have an ETEN advertisement brochure (dated dec/92) at hand. >It mentioned quite a large variant of fonts, so let's try >and see how we can incorporate them in our font properties. > >For example, the ETen "card" version include the following font "styles": >~{Cw~} ~{?,~} ~{A%~} ~{T2~} ~{:Z~} ~{PP~} > >For>~{Cw~} ~{T2~} ~{:Z~}>, each has the following "weights": > >~{5%O_~} ~{O8~} ~{VP~} ~{4V~} > >The simply character version also supports 3 styles: ~{KN~} ~{Cw~} ~{:Z~}. > >All these are call "~{Msince ETen also supports other "families", including: > ~{ND6&B96&WV~}>>~{;*?5WV~} (or so-called DYNAFONT) >presumably by 3rd-party font vendors. Perhaps "~{MSo, I disgree that "Song", "Kai", etc are FONT_FAMILIES. They ARE FONT_FAMILY names. I once saw a font sample poster from a Chinese publisher in Hong Kong. There were at least 100 font families. Most of them are variations of "Kai-shu", one of the 6 "shu" in caligraphy. -FFL From mcpong@cs.ust.hk Fri Apr 30 06:46:54 1993 Return-Path: Date: Fri, 30 Apr 93 19:14:48 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) To: soft-authors@ifcss.org Subject: zyg on X11 properties for full HBF Status: RO I have private communication with ygz and we more or less agreed that we need not do much to (re)define the X11R5 property values. (ygz will mail his utility shell scripts to check HBF.) We agree that we don't need to create new X11R5 property names. Here're some elaboration on some X11R5 property values for full HBF: (1) I'm pretty sure that "songti" is a style (or a font-family). Different vendors produce different "songti", but they have the same style ("fengge" ~{7g8q~}). "fangsong" is a kind of "ming" style font -- as far as I know: In Taiwan, more people call such style "ming". In the Mainland China, more call it "fangsong". Both of them are originated from "song" (i.e., "song" appeared first). One may argue that these are variants of "song". But like Times Roman and Times, they are now regarded as different FAMILY_NAME. --------- Different vendors/foundries produce the same styles of fonts. The information of different vendors can be coded in FONNDRY property. E.g. FOUNDRY "~{M For ~{Cw~} ~{T2~} ~{:Z~} , each has the following "weights": > > ~{5%O_~} ~{O8~} ~{VP~} ~{4V~} ygz wrote privately to me: > Here is verbatim from the ad: > > ~{2J:lAy:EVPND?(~} : > ~{?(IOLa9)CwLe#(5%O_#/O8#/VP#)#,T2Le#(5%O_#/O8#/VP#/4V#)#,:ZLe#(5%O_#/~} > ~{O8#/VP#/4V#)5HJ.R;LWM 13827 ~{WV5DH+WVPM#(5%O_LeN*~} 13104 ~{WV#)~} CCVICTOR@uxmail.ust.hk has supplied the following information: | I guess your information on ET rainbow card version is right. But | for the most popular ET ver 3.11 (which do not need a hardware card), | only six styles of normal weight are supported. The bold, thin and other | effects have to be done by the printing software or the word processor. | Of course the bold effect achieved by bitmap shifting is not as good as | those provided by a bold-font. | | I do agree that for serious users, different weight of one font style | should be provided as different set of fonts. For example, | the Topfont product (for ms-windows) contains 41 sets of font, | for the Hei (black) Ti alone, there are thin, middle, bold, | special (extra bold) and "A" variants. Please note that while the | thin and bold variants can be represented by a weight factor, there | are variants such as "A" which are not differ by weight but by a | minor style variation. | | Victor. I think we can assign whatever appropriate values for the X11R5 or HBF property WEIGHT_NAME. For the concern of ygz: >For example, the ETen "card" version include the following font "styles": >~{Cw~} ~{?,~} ~{A%~} ~{T2~} ~{:Z~} ~{PP~} > >For ~{Cw~} ~{T2~} ~{:Z~}>, each has the following "weights": > >~{5%O_~} ~{O8~} ~{VP~} ~{4V~} the HBF writer can specify these WEIGHT_NAME values for a particular font: WEIGHT_NAME "singlewidth" /* I suppose ~{5%O_~} ('thread' in Chinese) * means single line width stroke. * Or if one likes, one can use WEIGHT_NAME "thread" :-) */ WEIGHT_NAME "normal" WEIGHT_NAME "medium" WEIGHT_NAME "bold" It's up to the application to call HBF_GetProperty() which returns a string, but without any interpretation. It's up to the application to do the interpretation of the string. Any font server may wish to do whatever it wants with WEIGHT_NAME, e.g. matching a font with some user-specified vague requirement. ========== (3) I wrote: < [[ originally it's (draft 0.3) < ADD_STYLE_NAME "fanti" < Now I think to avoid ambiguity, spell "traditional hanzi" in full < to become < ADD_STYLE_NAME "fantizi" < ]] Now I think it should be ADD_STYLE_NAME "fantizixing" /* traditional hanzi glyph */ which specifies that the font's glyphs are those of traditional hanzi. Probably this property only appears for an HBF file for font indexed by GB code. If HBF_CODE_SCHEME GB2312-80 *and* the glyphs are for simplified hanzi, then there is no need to specify the property ADD_STYLE_NAME. mcpong P.S. The next mail is draft 0.4. From mcpong@cs.ust.hk Mon Apr 19 22:45:26 1993 Return-Path: Date: Tue, 20 Apr 93 11:37:41 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) To: soft-authors@ifcss.org Subject: updated API of HBF Std v1.0 Cc: mcpong@cs.ust.hk Status: RO After some private mail among tee@ecf.toronto.edu, ygz@cs.purdue.edu and me, we agree on updating the API: (1) to use * RETURN 0 if OK * or non-zero value if in error. In future versions of HBF, the non-zero value may be further specified to indicate different error conditions. (2) For HBF_GetBitmap(), use copy-out mechanism to return the sequence of bytes for the bitmap; i.e., the caller has to provide the storage space to store the "returned" bitmap. The API implementation can still use any internal buffer management or cache management scheme. This avoids undesirable consequences in multi-threads accessing the returned bitmap and in other situations. The copy-out mechanism is also good for Remote Procedure Call (RPC). (Say, it may be used in a font server.) The updated API is: int HBF_GetBitmap( IN HBF_Handle handle, IN HBF_HzCode hanziCode, INOUT HBF_BytePtr ptrBitmapBuffer ); /* Get the bitmap for the given hanzi code. * * The INOUT parameter "ptrBitmapBuffer" points to a buffer * large enough to store the byte sequence of the bitmap of * the hanzi. This routine will copy the bitmap sequence * into the buffer. * * RETURN 0 if the bitmap is found * or non-zero if invalid HBF handle or invalid hanzi code, * and the BitmapBuffer's content is undefined. */ /* N.B.: * It is up to the application to show the bitmap properly within * the FONTBOUNDINGBOX, if different from HBF_BITMAP_BOUNDING_BOX. */ /************************************************************/ It is up to the application program to allocate the space, either static, on stack, or dynamic allocated in heap, and guarantee that the space is there when HBF_GetBitmap is called. The API implementation doesn't need to worry about how that buffer is allocated or deallocated. An example of use is: #define HBF_OK 0 PrintGB(gbcode) { char bitmapBuffer[???]; if ( HBF_GetBitmap( fontHandle, gbcode, bitmapBuffer ) == HBF_OK ) { ShowBitmap( bitmapBuffer ); } } ============= (3) Same copy-out mechanism for returning the font handle in: int HBF_OpenFont( IN char * hbfFileName, INOUT HBF_Handle ptrHandleStorage ); /* Open and initialize an HBF file. * * The INOUT parameter "ptrHandleStorage" points to a storage * large enough to store the opened font handle. * This routine will assign the value of the opened handle * to this storage. * * RETURN 0 if the font given by the hbfFileName is opened successfully, * or non-zero if error. */ /************************************************************/ ============= If above is not objected by soft-authors, I'll send the updated HBF Standard v1.0 to xiaofei@ifcss.org so that he can put it in ifcss.org:/software/fonts/. mcpong From mcpong@cs.ust.hk Mon Apr 19 22:49:56 1993 Return-Path: Date: Tue, 20 Apr 93 11:40:42 HKT From: mcpong@cs.ust.hk (Dr. Man-Chi PONG) To: soft-authors@ifcss.org Subject: Update to previous mail Status: O > (3) Same copy-out mechanism for returning the font handle in: > > int HBF_OpenFont( > IN char * hbfFileName, > INOUT HBF_Handle ptrHandleStorage ); ^^^^^^^^^^ should be HBF_HandlePtr mcpong