Re: Full unicode support for back-xlib (2)
Fred Kiefer wrote: Hi Kazu, we now have reached a disagreement and need some more views on the remaining problems. Perhaps Nicola, Adam, Wim or Alex could join in and state their views on the use font sets. I am away for a few days anyway. Is this just about strtok or something else? It might be easier, to just write a quick parsing function in C that shows more transparently what is hapenning... I can't say I know a lot about the font issue, being a uni-lingual American (well I sort-of know some other languages, but living 1000 miles (er.. 1600km) from the nearest ocean makes it hard to find someone to practice with... I'd have to assume it works well for the people who use it. Note to Kazu: If you have CVS, it would be nice to have all the patches rolled into one instead of having a patch for each file. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Full unicode support for back-xlib (2)
Hi Fred, Wait a minute! I'm afraid you miss important points: (1) Does the code fail to work? (2) Does it mix up Adobe fonts together to draw strings? (Hopefully, not.) Answers to the questions above don't depend on the disagreement. Cheers, - Kazu Fred Kiefer wrote: Hi Kazu, we now have reached a disagreement and need some more views on the remaining problems. Perhaps Nicola, Adam, Wim or Alex could join in and state their views on the use font sets. I am away for a few days anyway. Cheers Fred Kazunobu Kuriyama wrote: Fred Kiefer wrote: It is even worse, the man page says: BUGS Never use these functions. If you do, note that: These functions modify their first argument. These functions cannot be used on constant strings. The identity of the delimiting character is lost. The strtok() function uses a static buffer while parsing, so it's not thread safe. Use strtok_r() if this matters to you. I don't think that this could cause any harm in your case, still I would avoid it. Taking all the points above into consideration, I did it. Hopefully, harmless. Though the current code might look a bad programming style, I think it is the right place to compromise. I was also worried about the special treatment you do for missing add styles, as I can tell from the fonts installed on my machine almost any part of a XLFD may be missing, this should not cause any special treatment. I simply need to distinguish the token '--' from the token '-'. It could be written in a more generalized way, but it would results in over-engineering. You can't use the return value of XGFontName() directly to load multiple fonts with XCreateFontSet() because XGFontName() is biased in favor of European fonts (see below). The code which looks special to you absorbs this GNUstep's specialization. As for the latter question: People can't expect every font on the earth has the family property called 'Helvetica', 'Courier' or something else which is taken for granted in Latin characters, while they can find fonts with the foundry property such as 'Adobe' and 'fixed'.. The current implementation reflects this reality. (Because I thought this was a common knowledge, I didn't document it in detail. This gives another example that people always think their own ways as 'the' standard, doesn't this?) Are you saying that for Asian fonts there is no such thing as a font family? Or do they just have different names not Helvetica, which is what I would expect. I didn't say Asian fonts have no font family. When I checked the state of the internal variables of GNUstep related to fonts, I found that it exclusively uses Helvetica, Courier or something like that. You'll never find Japanese Helvetica, Chinese Courier, Korean Times, Thai Utopia, ... (If I remember correctly, Alexander Malmberg once told us in discuss-gnustep that he considered to make the family specification user-configurable.) We seem to have a real problem here. On my machine I have about 10 different fonts from Adobe installed (of course each with dozens of styles and sizes). They have a totally different appearance and I never would want to mix them when displaying a string. Whereas I would not mind to mix Helvetica coming from different sources. Your current implementation of building up font sets would be rather unusable for any European language user (probably even for US Americans, but you never can tell), as this would merge fonts that don't belong together. Don't worry. The X server tries loading two or more fonts only if it needs to do so. This is done based on the locale in use. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Full unicode support for back-xlib (2)
Hi Kazu, we now have reached a disagreement and need some more views on the remaining problems. Perhaps Nicola, Adam, Wim or Alex could join in and state their views on the use font sets. I am away for a few days anyway. Cheers Fred Kazunobu Kuriyama wrote: Fred Kiefer wrote: It is even worse, the man page says: BUGS Never use these functions. If you do, note that: These functions modify their first argument. These functions cannot be used on constant strings. The identity of the delimiting character is lost. The strtok() function uses a static buffer while parsing, so it's not thread safe. Use strtok_r() if this matters to you. I don't think that this could cause any harm in your case, still I would avoid it. Taking all the points above into consideration, I did it. Hopefully, harmless. Though the current code might look a bad programming style, I think it is the right place to compromise. I was also worried about the special treatment you do for missing add styles, as I can tell from the fonts installed on my machine almost any part of a XLFD may be missing, this should not cause any special treatment. I simply need to distinguish the token '--' from the token '-'. It could be written in a more generalized way, but it would results in over-engineering. You can't use the return value of XGFontName() directly to load multiple fonts with XCreateFontSet() because XGFontName() is biased in favor of European fonts (see below). The code which looks special to you absorbs this GNUstep's specialization. As for the latter question: People can't expect every font on the earth has the family property called 'Helvetica', 'Courier' or something else which is taken for granted in Latin characters, while they can find fonts with the foundry property such as 'Adobe' and 'fixed'.. The current implementation reflects this reality. (Because I thought this was a common knowledge, I didn't document it in detail. This gives another example that people always think their own ways as 'the' standard, doesn't this?) Are you saying that for Asian fonts there is no such thing as a font family? Or do they just have different names not Helvetica, which is what I would expect. I didn't say Asian fonts have no font family. When I checked the state of the internal variables of GNUstep related to fonts, I found that it exclusively uses Helvetica, Courier or something like that. You'll never find Japanese Helvetica, Chinese Courier, Korean Times, Thai Utopia, ... (If I remember correctly, Alexander Malmberg once told us in discuss-gnustep that he considered to make the family specification user-configurable.) We seem to have a real problem here. On my machine I have about 10 different fonts from Adobe installed (of course each with dozens of styles and sizes). They have a totally different appearance and I never would want to mix them when displaying a string. Whereas I would not mind to mix Helvetica coming from different sources. Your current implementation of building up font sets would be rather unusable for any European language user (probably even for US Americans, but you never can tell), as this would merge fonts that don't belong together. Don't worry. The X server tries loading two or more fonts only if it needs to do so. This is done based on the locale in use. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Full unicode support for back-xlib (2)
Fred Kiefer wrote: Fred Kiefer wrote: > > - As XGFontSetEnumerator is currently not implemented I would remove > all reverences to it. (Reading references for reverences,) At first, I declared XGFontSetEnumerator without implementation, and then I got an exception telling me that enumerateFontsAndFamilies should be overridden. So I put the stub of it to make the module work. This is the only reason I did it. If the declaration is unnecessary and is the cause of throwing the exception, your suggestion is helpful to make the implementation better. I meant to remove the whole class until there is real code for it. Enclosed with #if 0 and #endif. It is even worse, the man page says: BUGS Never use these functions. If you do, note that: These functions modify their first argument. These functions cannot be used on constant strings. The identity of the delimiting character is lost. The strtok() function uses a static buffer while parsing, so it's not thread safe. Use strtok_r() if this matters to you. I don't think that this could cause any harm in your case, still I would avoid it. Taking all the points above into consideration, I did it. Hopefully, harmless. Though the current code might look a bad programming style, I think it is the right place to compromise. I was also worried about the special treatment you do for missing add styles, as I can tell from the fonts installed on my machine almost any part of a XLFD may be missing, this should not cause any special treatment. I simply need to distinguish the token '--' from the token '-'. It could be written in a more generalized way, but it would results in over-engineering. You can't use the return value of XGFontName() directly to load multiple fonts with XCreateFontSet() because XGFontName() is biased in favor of European fonts (see below). The code which looks special to you absorbs this GNUstep's specialization. As for the latter question: People can't expect every font on the earth has the family property called 'Helvetica', 'Courier' or something else which is taken for granted in Latin characters, while they can find fonts with the foundry property such as 'Adobe' and 'fixed'.. The current implementation reflects this reality. (Because I thought this was a common knowledge, I didn't document it in detail. This gives another example that people always think their own ways as 'the' standard, doesn't this?) Are you saying that for Asian fonts there is no such thing as a font family? Or do they just have different names not Helvetica, which is what I would expect. I didn't say Asian fonts have no font family. When I checked the state of the internal variables of GNUstep related to fonts, I found that it exclusively uses Helvetica, Courier or something like that. You'll never find Japanese Helvetica, Chinese Courier, Korean Times, Thai Utopia, ... (If I remember correctly, Alexander Malmberg once told us in discuss-gnustep that he considered to make the family specification user-configurable.) We seem to have a real problem here. On my machine I have about 10 different fonts from Adobe installed (of course each with dozens of styles and sizes). They have a totally different appearance and I never would want to mix them when displaying a string. Whereas I would not mind to mix Helvetica coming from different sources. Your current implementation of building up font sets would be rather unusable for any European language user (probably even for US Americans, but you never can tell), as this would merge fonts that don't belong together. Don't worry. The X server tries loading two or more fonts only if it needs to do so. This is done based on the locale in use. I'd like it if the development team would allow me to do so. I guess we need a new boolean user default value, say, GSEnableXFontSet or GSXEnableFontSet (or, FontSet may be replaced with MultiByte). Could you suggest me a better name? These two names sound fine for me, the later is perhaps a bit closer to what we have there already. Go ahead and add this, but dont forget to document it in back/Documentation/Back/DefaultsSummary.gsdoc. I think for the start the default should be NO, but we may change this as this option gets tested more. OK, I will use GSXEnableFontSet and set its default to NO. - Kazu ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Full unicode support for back-xlib (2)
Kazunobu Kuriyama wrote: Thank you for reading the code very carefully and extensively. This is what we should do a lot more, normally we don't have the time for it, but this time I owe it to you. Fred Kiefer wrote: > > - As XGFontSetEnumerator is currently not implemented I would remove > all reverences to it. (Reading references for reverences,) At first, I declared XGFontSetEnumerator without implementation, and then I got an exception telling me that enumerateFontsAndFamilies should be overridden. So I put the stub of it to make the module work. This is the only reason I did it. If the declaration is unnecessary and is the cause of throwing the exception, your suggestion is helpful to make the implementation better. I meant to remove the whole class until there is real code for it. > - My man pages warn about the use of the funtion strtok(). Why not > pass into load_font_set() the NSString and use > [componentsSeparatedByString:] (This method is also use in the > font_chacher.m)? I guess your man pages tell you that strtok() modifies a given original string, replacing a delimiter with a whitespace. Because the current implmenetation invokes strtok() against a copy of the original string, not the original one, I don't think the warning makes the case. It is even worse, the man page says: BUGS Never use these functions. If you do, note that: These functions modify their first argument. These functions cannot be used on constant strings. The identity of the delimiting character is lost. The strtok() function uses a static buffer while parsing, so it's not thread safe. Use strtok_r() if this matters to you. I don't think that this could cause any harm in your case, still I would avoid it. I intentionally and extensively make use of the C library functions over there because of efficiency. As you can see, we need many system calls and communications with the X server there, which inevitably and significantly make programs crawl. If this does not make sense, I agree to the opinion that use of NSString would be better. As you said, there are a lot of X calls involced, which may take some time, therefor it should not be to bad to work with ObjC objects in the rest of the code, as they are most certainly faster than the X calls. Though the current code might look a bad programming style, I think it is the right place to compromise. I was also worried about the special treatment you do for missing add styles, as I can tell from the fonts installed on my machine almost any part of a XLFD may be missing, this should not cause any special treatment. > > In this part of the code I am also a bit unsure about the pieces of > > the XLFD that you use and the ones you discard. Could you explain, > > document what you do and why? (For example, I would use the family and > > discard the foundry, you do the opposit) As for the latter question: People can't expect every font on the earth has the family property called 'Helvetica', 'Courier' or something else which is taken for granted in Latin characters, while they can find fonts with the foundry property such as 'Adobe' and 'fixed'.. The current implementation reflects this reality. (Because I thought this was a common knowledge, I didn't document it in detail. This gives another example that people always think their own ways as 'the' standard, doesn't this?) Are you saying that for Asian fonts there is no such thing as a font family? Or do they just have different names not Helvetica, which is what I would expect. We seem to have a real problem here. On my machine I have about 10 different fonts from Adobe installed (of course each with dozens of styles and sizes). They have a totally different appearance and I never would want to mix them when displaying a string. Whereas I would not mind to mix Helvetica coming from different sources. Your current implementation of building up font sets would be rather unusable for any European language user (probably even for US Americans, but you never can tell), as this would merge fonts that don't belong together. > - What we could also think of is to make the switch between your and > the standard implementation of font handling one at runtime. Allowing > for a simpler transistion without recompiling the backend each time. > See the user default for the use of the XFT fonts. > I'd like it if the development team would allow me to do so. I guess we need a new boolean user default value, say, GSEnableXFontSet or GSXEnableFontSet (or, FontSet may be replaced with MultiByte). Could you suggest me a better name? These two names sound fine for me, the later is perhaps a bit closer to what we have there already. Go ahead and add this, but dont forget to document it in back/Documentation/Back/DefaultsSummary.gsdoc. I think for the start the default should be NO, but we may change this as this opt
Re: Full unicode support for back-xlib (2)
Hi Fred, Thank you for reading the code very carefully and extensively. Fred Kiefer wrote: > > - As XGFontSetEnumerator is currently not implemented I would remove > all reverences to it. (Reading references for reverences,) At first, I declared XGFontSetEnumerator without implementation, and then I got an exception telling me that enumerateFontsAndFamilies should be overridden. So I put the stub of it to make the module work. This is the only reason I did it. If the declaration is unnecessary and is the cause of throwing the exception, your suggestion is helpful to make the implementation better. > > - [initWithFontName:matrix:screenFont:] may lead to memory leaks as > RELEASE(self) is missing for all the error cases. That's simply due to my carelessness. > > - char_struct_for_glyph() could return a boolean value if the chracter > was found. Thereby making all the calls, especially [glyphIsEncoded:] > a lot simple and removing the need of memset() inside this function. I agree. This part of the currrent implementation looks quite agly. > > - My man pages warn about the use of the funtion strtok(). Why not > pass into load_font_set() the NSString and use > [componentsSeparatedByString:] (This method is also use in the > font_chacher.m)? > In this part of the code I am also a bit unsure about the pieces of > the XLFD that you use and the ones you discard. Could you explain, > document what you do and why? (For example, I would use the family and > discard the foundry, you do the opposit) I guess your man pages tell you that strtok() modifies a given original string, replacing a delimiter with a whitespace. Because the current implmenetation invokes strtok() against a copy of the original string, not the original one, I don't think the warning makes the case. I intentionally and extensively make use of the C library functions over there because of efficiency. As you can see, we need many system calls and communications with the X server there, which inevitably and significantly make programs crawl. If this does not make sense, I agree to the opinion that use of NSString would be better. Though the current code might look a bad programming style, I think it is the right place to compromise. As for the latter question: People can't expect every font on the earth has the family property called 'Helvetica', 'Courier' or something else which is taken for granted in Latin characters, while they can find fonts with the foundry property such as 'Adobe' and 'fixed'.. The current implementation reflects this reality. (Because I thought this was a common knowledge, I didn't document it in detail. This gives another example that people always think their own ways as 'the' standard, doesn't this?) > - What we could also think of is to make the switch between your and > the standard implementation of font handling one at runtime. Allowing > for a simpler transistion without recompiling the backend each time. > See the user default for the use of the XFT fonts. > I'd like it if the development team would allow me to do so. I guess we need a new boolean user default value, say, GSEnableXFontSet or GSXEnableFontSet (or, FontSet may be replaced with MultiByte). Could you suggest me a better name? - Kazu ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Full unicode support for back-xlib (2)
Hi Kazu, this patch looks great! There a only a few things I would like to change: - As XGFontSetEnumerator is currently not implemented I would remove all reverences to it. - [initWithFontName:matrix:screenFont:] may lead to memory leaks as RELEASE(self) is missing for all the error cases. - char_struct_for_glyph() could return a boolean value if the chracter was found. Thereby making all the calls, especially [glyphIsEncoded:] a lot simple and removing the need of memset() inside this function. - My man pages warn about the use of the funtion strtok(). Why not pass into load_font_set() the NSString and use [componentsSeparatedByString:] (This method is also use in the font_chacher.m)? In this part of the code I am also a bit unsure about the pieces of the XLFD that you use and the ones you discard. Could you explain, document what you do and why? (For example, I would use the family and discard the foundry, you do the opposit) - What we could also think of is to make the switch between your and the standard implementation of font handling one at runtime. Allowing for a simpler transistion without recompiling the backend each time. See the user default for the use of the XFT fonts. Cheers Fred Kazunobu Kuriyama wrote: Based on Fred Kiefer's suggestion, I rewrote the patches I previously sent to bug-gnustep with the email 'Full unicode support for back-xlib'. A few bug fixes have also been done. While the functionality the new patches offer remains the same as that of the previous ones, both the organization and the performance are improved. The main differences are: (1) The part that was included in XGSFont.m.patch becomes two new files, XGFontSetFontInfo.h and XGFontSetFontInfo.m. (2) The new module resulting from these files is used in XGContext.m. As a result, the new module can be handled similarly to those of XGFont.m and GSXftFontInfo.m. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
