Re: [Fonts]edit antialias=false equivalent in fonts.conf
Can you provide screenshots supporting this? Together with testing details? OK, second try, the first time i replied, my message got caught by the mailing list for being too big. Whoever is the admin, if you could please let it through.. For now, I made another imaget that explores a different point. http://taroboy.mine.nu:8001/pictures/comparison.png This pictures is meant to illustrate several scaling methods and their effect on a commonly used free japanese ttf. (kochi gothic) The big string at the very top, is the xtt module's rendering of kochi gothic at a 128 pixel size. The set of smaller strings in the first group are the original 128 pix rendering scaled down to the following sizes: 64 pix, 32 pix, 24 pix, 16 pix, 12pix, and 8 pix. Each size is scaled directly down from the 128 pix rendering. Gimp's image resize feature is used for the scaling. The second group is the same set, except the scaling is done by xtt. (xtt uses embedded bitmaps where available, so u can see that the 16pt and 12pt versions look significantly different from the rest) The third set is a rendering by Xft1, which I got by taking screenshots of gedit2 with the font size set at various sizes. Observations: 1. though no one will realistically use the 8 pix size it seems the output of the first method (gimp scaling) produces the best results, though Xft output isn't bad either. The xtt output is pretty difficult to read. 2. For larger sizes (32 pix and above) it seems Xft is the winner. Especially the 128 pix rendering, Xft looks the best. For smaller sizes however, (24, 16, 12) I tend to feel that the first scaling method produces more consistent stroke widths. (look at the 8th character of the phrase, compare the one in the first group and the last group for the 24pix rendering.. tho this may be because of bad hinting..) For the 16 pix rendering, group 1's (gimp scaling) output is significantly more stylistically consistent when compared to group 3 (xft). Same with the 12pix. The embedded fonts in group 2, unfortunately, are a set of bitmap fonts created by a different author than the kochi gothic author, so they look different from the outline renderings by design, not by error. It seems like the 6th character would prove most difficult, because it has the most strokes but actually I see a lot more rendering variation of the 8th character than the 6th, most likely because it contains so many parallel horizontal lines. Either way, I still like group 1's scalign of the 8th character the most, especially if u look at the 12 pix rendering. Anyhow, hopefull the admin will let my other message through, which has attached a pic comparing mozilla bitmap scaling and xft rendering. If it doesn't show up, I'll just post the url like i did for this one. Ken ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]edit antialias=false equivalent in fonts.conf
On Wednesday 28 August 2002 8:53 pm, Brian Stell wrote: | Ken Deeter (Kentarou SHINOHARA) wrote: | ... | Hmm.. i'm not sure this would be so helpful for kanji characters | since often two parallel one-pixel width lines will be one pixel | apart. Any grayness in between will just make things look really | smudged. | | I have very similar concerns for scaling Kanji bitmaps in mozilla | but the Japanese and Chinese useres I've talked to report that | they really like it and I have not had any negative reports. | | Also see chapter 2 of the Truetype spec: | | http://www.microsoft.com/typography/tt/tt.htm | |EBSC - Embedded Bitmap Scaling Table | |The EBSC table provides a mechanism for describing embedded |bitmaps which are created by scaling other embedded bitmaps. |While this is the sort of thing that outline font technologies |were invented to avoid, there are cases (small sizes of Kanji, |for example) where scaling a bitmap produces a more legible |font than scan-converting an outline. For this reason the |EBSC table allows a font to define a bitmap strike as a |scaled version of another strike. Now we just need to get it supported in PfaEdit :-) -- Vadim Plessky http://kde2.newmail.ru (English) 33 Window Decorations and 6 Widget Styles for KDE http://kde2.newmail.ru/kde_themes.html KDE mini-Themes http://kde2.newmail.ru/themes/ ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]edit antialias=false equivalent in fonts.conf
On Thu, 29 Aug 2002 11:25:44 +0400 Vadim Plessky [EMAIL PROTECTED] wrote: Can you provide screenshots supporting this? Together with testing details? Hmm, i can try.. i was sorta just stating my opinion.. but I'll see what i can dig up. Which outlines do you render to? Hinted or non-hinted? PS Type1 or TrueType? my general experience is with the Kochi Gothic TTF and several of the microsoft japanese ttf's (ms mincho, ms gothic, ms ui gothic) Does someone use kanji at 8px? Even Latin alphabet is not very easy to read at 8px. woops, sorry i meant 10px.. which is still extremely tiny.. but such a japanese font exists and is useful in some situations. i don't think it helps that japanese people are used to extremely small characters (just look at japanese news paper print.. old people in japan can barely read it) ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]edit antialias=false equivalent in fonts.conf
Keith == Keith Packard [EMAIL PROTECTED] writes: Keith I'd say that the question of whether you want to use the Keith embedded bitmaps is essentially the same as to whether you want Keith to use anti-aliasing. Well hinted Western fonts are Keith essentially equivalent to embedded bitmaps. On a related note, it may be worthwhile to offer the option of aa-ing bitmaps (embedded or otherwise). AA improves even the best-instructed ttfs even though only curves and diagonals are changed. Bitmaps can benefit from that just as much as well-instructed ttfs. How much work would it take to support that? -JimC ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]edit antialias=false equivalent in fonts.conf
Hi, There are a lot of knobs to turn in selecting how to render fonts. What I'd like to see is some consistent set of orthogonal knobs all layed out together. Continuing down our current path of a random set of variables seems like a bad plan. Besides AA, embedded bitmap, and subpixel rendering, what is other knobs?? Gamma correction? Scaling? Boldening? or I totally get the wrong direction?? I don't know much, as I'm still a new commer on typography!! Zenith ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]edit antialias=false equivalent in fonts.conf
Ken Deeter (Kentarou SHINOHARA) wrote: ... Hmm.. i'm not sure this would be so helpful for kanji characters since often two parallel one-pixel width lines will be one pixel apart. Any grayness in between will just make things look really smudged. I have very similar concerns for scaling Kanji bitmaps in mozilla but the Japanese and Chinese useres I've talked to report that they really like it and I have not had any negative reports. Also see chapter 2 of the Truetype spec: http://www.microsoft.com/typography/tt/tt.htm EBSC - Embedded Bitmap Scaling Table The EBSC table provides a mechanism for describing embedded bitmaps which are created by scaling other embedded bitmaps. While this is the sort of thing that outline font technologies were invented to avoid, there are cases (small sizes of Kanji, for example) where scaling a bitmap produces a more legible font than scan-converting an outline. For this reason the EBSC table allows a font to define a bitmap strike as a scaled version of another strike. -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]edit antialias=false equivalent in fonts.conf
I have very similar concerns for scaling Kanji bitmaps in mozilla but the Japanese and Chinese useres I've talked to report that they really like it and I have not had any negative reports. I've played with this feature in mozilla as well, and I tend to like it better than the fuzziness that freetype produces. (tho arguably mozilla and freetype both produce fuzzy output) I think it may have to do with the fact that for kanji characters, proportion and uniformity are more important than just line clarity. Ie if a character has three parallel horizontal lines that are supposed to be of equal thickness, it seems better that these three lines are uniformly smudged rather than one being noticeably thicker or thinner than the other two. I think bitmap scaling tends to preserve the uniformity and proportion that exists in the high res versions, whereas rendering outlines doesn't always maintain these characteristics. (sorry this is hand waving at best... don't quote me, its just my theory for now) Also, nautilus1's antialiased rendering of japanese characters was quite legible as well, if I recall correctly. I don't know what they did there.. The only other thing that worries me tho, is that for really small sizes, like 8 pix, kanji characters are often heavily distorted to fit into that space, sometimes so much so that i don't think any amount of hinting can replicate. And at this size, scaling bitmaps down would just produce a big gray dot i would suspect. ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]edit antialias=false equivalent in fonts.conf
Around 17 o'clock on Aug 27, Ken Deeter wrote: Is it possible to replicate the behavior of: match any size 14 any size 8 edit antialias=false; Yes. See the example fonts.conf file and the manual page for the new XML-based syntax. Also, if I do do this, then will Xft now use the embedded bitmaps for the non-antialiased sizes or will it try to use the outlines like before? Xft1 still has the old (broken) behaviour. The current version of Xft uses bitmaps when antialiasing is disabled. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]edit antialias=false equivalent in fonts.conf
Xft1 still has the old (broken) behaviour. The current version of Xft uses bitmaps when antialiasing is disabled. it seems for asian fonts at least, if there are embedded bitmaps, they should be used even if antialiasing is enabled. (i think this is what xp does, not that we should always replicate xp) Or it would be helpful if there was an option to enable this kind of behaviour. (I apologize if there already is) I suspect diff ttf's provide different size ranges of embedded bitmaps, and it would be a humongous pain to go thru and match each font specifically to turn antialiasing off. I guess I will have to wait till xft2 is out and about. Thanks, ken ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]edit antialias=false equivalent in fonts.conf
On Tue, 27 Aug 2002 21:41:14 -0700 Keith Packard [EMAIL PROTECTED] wrote: There are a lot of knobs to turn in selecting how to render fonts. What I'd like to see is some consistent set of orthogonal knobs all layed out together. Continuing down our current path of a random set of variables seems like a bad plan. If I may make a suggestion with regards to this issue. There should be two switches to control rendering at the highest level. 1. Anti-aliased rendering switch 2. Embedded-bitmap override switch for the purpose of illustration, i'll call them AAR and EBO respectively The AAR switch simply does what its name suggests. Turns global anti-aliased rendering on and off. When AAR is on, fonts should be rendered with AA enabled. With AAR off, fonts should be rendered without anti-aliasing. The EBO switch only makes a difference when AAR is on. When AAR is off, embedded bitmaps should be used where available. When AAR is on, however, embedded bitmaps be used only when the EBO switch is on. The theory behind doing things this way is based the following assumption: Embedded bitmaps are provided where hinting isn't (for whatever reason), or where anti-aliasing isn't practical (read high density kanji/chinese characters). Since western fonts are often properly hinted, there is no reason for embedded bitmaps to be included, and thus the EBO switch has no affect on them at all. I think there is still a question of whether the feature of being able to turn anti aliasing on and off by size is still useful, considering the fact that embedded bitmaps are now supported. Since its already there, I guess there's no point taking it out, but it seems like a pretty minor feature that most gui systems don't support. Poorly hinted fonts without embedded bitmaps are going to look bad either way. Ken ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
