[Fonts] Are you learning ESL or TESL?
Dear Reader... No More Accent is an accent reduction product, which helps to remove accents. For example, an Asian lady (or any nationality) may have communication problems with her English when speaking to her friends or business colleagues. With that in mind, No More Accent teaches Accent Reduction methodologies to help in this area. In fact, No More Accent can be used in almost any situation where an accent reduction is required. Even Actors within the Entertainment Industry have turned to No More Accent as a way to lose or gain an accent of another nationality. No More Accent is available in two versions, CD-ROM and VHS Cassette Tape (PAL and NTSC formats) both can be purchased directly via the http://www.no-more-accents.com website. If you would like further information about our products or services, please contact myself when you have a moment. Best Wishes... Natalie Edwards Marketing Co-ordinator http://www.no-more-accents.com Your #1 Resource for Accent Reduction!
[Fonts] Re: two different gb18030.2000-1 : Sun/Mozilla/Java vs RH
On Wed, 9 Jul 2003, Yu Shao wrote: Jungshik Shin wrote: On Tue, 8 Jul 2003, Yu Shao wrote: I don't get you here, the first version of the patch was made for Red Hat 7.3, at that time we have to use Mozilla with X core font. Since then the patch has been there almost unchanged. GB18030.2000* aliases were added purely because we want Mozilla working (you made gb18030.2000-0 an alias to gbk-0, but you also made a new identity mapping for gb18030.2000-1. They're different/separate issues that cannot be aggregated with '*'.) As I wrote, Mozilla's GB18030Font1 is NOT your gb18030.2000-1.enc BUT Sun's gb18030.2000-1 (and what's proposed by James Su and Roland Mainz). There's NO dispute about gb18030.2000-0. The question is about gb18030.2000-1 (not '0'). With this difference, how could you make Mozilla (non-Xft build) work with your gb18030.2000-1? Probably, it gave you an impression that it worked either because you also had iso10646-1 fonts or because you haven't checked BMP characters _outside_ the repertoire of gb18030.2000-0 with Mozilla. About the identical mapping in RedHat's GB18030.2000-1, it is because the inside compound encoding part is treating them as ISO10646 codes. This is a bit confusing. How am I supposed to interpret this together with the first sentennce in your reply? Do you need RH8's version of gb18030.2000-1.enc or not? This question of mine is about Compound text encoding. You began your reply with the following. Because RedHat XFree86 18030 patch's compound text encoding part was based on James Su's patch which was derived from UTF-8' code, it doesn't really need GB18030.2000-0.enc and GB18030.200-1.enc to be functioning. and then ended it with 'About the identical mapping the inside compound ... is treating them as ..'. To me it appears to contradict each other. How would you propose the conflict between RH's gb18030.2000-1.enc and Solaris/Mozilla/Java's gb18030.2000-1 be solved? Could you add your comment to http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=441 ? What GB18030 compound encoding code has XFree86 decided to use? right now, there is even no GB18030 X locale definition in CVS, there is no conflict, just totally depends on how to approach the compound text encoding part. Let me make it clear. The conflict is not inside XFree86 but between RH8's gb18030.2000-1 on the one hand and Sun's and Mozilla's gb18030.2000-1 (and what James Su and Romland Mainz proposed) on the other hand. It's regrettable that your patch hasn't been discussed in open forums like fonts/i18n list of XFree86 IIRC (my memory sometimes doesn't serve me well so that I may have missed it). Do you care which of two gb18030.2000-1's is included in XFree86, do you? If you don't care, you're willing to replace RH's gb18030.2000-1.enc with that based on Sun's/Mozilla's/Java's (as suggested by James Su in http://www.mail-archive.com/fonts%40xfree86.org/msg01343.html or by Roland in http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=441) Independent of compound text encoding, it's bad that gb18030.2000-1 has two different meanings. That's what I want to resolve here. If you agree to go with Sun's version, we won't have to worry about having to figure out which is which (although x11 core fonts become less and less important...) Jungshik ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Encodings XLFDs within sfnt
In order to preserve bitmap font names as we switch to sfnt for XFree86, I need to have fonttosfnt put the original font name in some place where mkfontscale can find it. The proper way would be to formally define a new sfnt table, for example ``XF86''. However, I think it is simpler and quite as reliable to put a non-standard signature in some standard place. I'm currently tempted to use the ``comment'' string in the ``name'' table. I could generate it to be XFree86 font, original name was -misc-fixed-... and then check for this string. Comments? Better ideas? Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] Re: two different gb18030.2000-1 : Sun/Mozilla/Java vsRH
I want to make one point clear, that is *.enc encoding files are used by fontenc layer only, adding gb18030.2000*.enc doesn't mean telling XFree86 how to handle gb18030 codes in all parts, but in fontenc layer(FreeType module) ONLY. Looking at Sun's gb18030.2000-1, they seem convert all four-bytes into two-bytes starting from 0x, then process them as 2 two-byte inside, when displaying it, fontenc will look up gb18030.2000-1 to display the font. There is no conflict whatsoever, just like i said, totally depends on how to process them inside encoding part. Yu Shao Jungshik Shin wrote: On Wed, 9 Jul 2003, Yu Shao wrote: Jungshik Shin wrote: On Tue, 8 Jul 2003, Yu Shao wrote: I don't get you here, the first version of the patch was made for Red Hat 7.3, at that time we have to use Mozilla with X core font. Since then the patch has been there almost unchanged. GB18030.2000* aliases were added purely because we want Mozilla working (you made gb18030.2000-0 an alias to gbk-0, but you also made a new identity mapping for gb18030.2000-1. They're different/separate issues that cannot be aggregated with '*'.) As I wrote, Mozilla's GB18030Font1 is NOT your gb18030.2000-1.enc BUT Sun's gb18030.2000-1 (and what's proposed by James Su and Roland Mainz). There's NO dispute about gb18030.2000-0. The question is about gb18030.2000-1 (not '0'). With this difference, how could you make Mozilla (non-Xft build) work with your gb18030.2000-1? Probably, it gave you an impression that it worked either because you also had iso10646-1 fonts or because you haven't checked BMP characters _outside_ the repertoire of gb18030.2000-0 with Mozilla. About the identical mapping in RedHat's GB18030.2000-1, it is because the inside compound encoding part is treating them as ISO10646 codes. This is a bit confusing. How am I supposed to interpret this together with the first sentennce in your reply? Do you need RH8's version of gb18030.2000-1.enc or not? This question of mine is about Compound text encoding. You began your reply with the following. Because RedHat XFree86 18030 patch's compound text encoding part was based on James Su's patch which was derived from UTF-8' code, it doesn't really need GB18030.2000-0.enc and GB18030.200-1.enc to be functioning. and then ended it with 'About the identical mapping the inside compound ... is treating them as ..'. To me it appears to contradict each other. How would you propose the conflict between RH's gb18030.2000-1.enc and Solaris/Mozilla/Java's gb18030.2000-1 be solved? Could you add your comment to http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=441 ? What GB18030 compound encoding code has XFree86 decided to use? right now, there is even no GB18030 X locale definition in CVS, there is no conflict, just totally depends on how to approach the compound text encoding part. Let me make it clear. The conflict is not inside XFree86 but between RH8's gb18030.2000-1 on the one hand and Sun's and Mozilla's gb18030.2000-1 (and what James Su and Romland Mainz proposed) on the other hand. It's regrettable that your patch hasn't been discussed in open forums like fonts/i18n list of XFree86 IIRC (my memory sometimes doesn't serve me well so that I may have missed it). Do you care which of two gb18030.2000-1's is included in XFree86, do you? If you don't care, you're willing to replace RH's gb18030.2000-1.enc with that based on Sun's/Mozilla's/Java's (as suggested by James Su in http://www.mail-archive.com/fonts%40xfree86.org/msg01343.html or by Roland in http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=441) Independent of compound text encoding, it's bad that gb18030.2000-1 has two different meanings. That's what I want to resolve here. If you agree to go with Sun's version, we won't have to worry about having to figure out which is which (although x11 core fonts become less and less important...) Jungshik ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Bitmap-only SFNTs: initial code in CVS
It is now possible to use bitmap-only SFNTs in XFree86. There is very
little left to do at the server level, some more work is needed at the
level of fonttosfnt and mkfontscale.
0. Check you've got the right version of XFree86.
$ cvs log xc/lib/font/fontfile/fontdir.c | grep 289
289. Twisting fontfile.c and fontdir.c to be able to pass all fonts (bitmap
1. Apply
http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=491
and rebuild mkfontscale.
2. Make a directory full of fonts.
$ cd /tmp
$ mkdir fonts
$ cd fonts
$ cp /usr/X11R6/lib/X11/fonts/misc/*.pcf.gz .
3. Uncompress the fonts. This is optional, but if you don't do that,
the next step will take minutes rather than seconds.
$ gzip -d *.pcf.gz
4. Convert all the fonts to bitmap-only sfnt, and give them the
extension ttf (for now -- see my next message):
$ for i in *.pcf; do fonttosfnt -o ${i%.pcf}.ttf $i ; done
$ rm *.pcf
You will get a number of failures, I'm looking into that.
5. Create a fonts.dir file:
$ mkfontscale -b
You'll get some warnings, and some of the generated names will not be
quite right. Additionally, all non-Unicode fonts will get names
ending in ``microsoft-symbol''. (Fixing that will require private
extensions to the sfnt format.)
6. Test the new fonts.
$ xset +fp `pwd`
$ xlsfonts -ll -fn '-misc-fixed-medium-r-normal--20-*-75-75-m-*-iso8859-1' | grep
RASTERIZER_NAME
RASTERIZER_NAME FreeType
$ xfd -fn '-misc-fixed-medium-r-normal--20-*-75-75-m-*-iso8859-1'
Juliusz
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] Bitmap-only SFNTs: initial code in CVS
4. Convert all the fonts to bitmap-only sfnt, and give them the
extension ttf (for now -- see my next message):
$ for i in *.pcf; do fonttosfnt -o ${i%.pcf}.ttf $i ; done
$ rm *.pcf
Sorry, forgot an important step: transcoded fonts should be removed,
on-the-fly transcoding will happen.
$ rm *-*-*.pcf
$ for i in *.pcf; do fonttosfnt -o ${i%.pcf}.ttf $i ; done
$ rm *.pcf
Juliusz
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Re: [Freetype] Encodings XLFDs within sfnt
In order to preserve bitmap font names as we switch to sfnt for XFree86, I need to have fonttosfnt put the original font name in some place where mkfontscale can find it. The proper way would be to formally define a new sfnt table, for example ``XF86''. However, I think it is simpler and quite as reliable to put a non-standard signature in some standard place. Why do you think it is more complicated to add a new sfnt table? I'm currently tempted to use the ``comment'' string in the ``name'' table. I could generate it to be XFree86 font, original name was -misc-fixed-... and then check for this string. Hmm, an XF86 table would also allow to store unconverted BDF properties which are lost otherwise. I vote for an XF86 sfnt table. Werner ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
