Re: Sugar's fonts
On 9/30/07, Albert Cahalan [EMAIL PROTECTED] wrote: Western fonts also do not have bold or italic built-in. It is common to have several similar fonts, called a font family, to solve this problem. The bold and italic versions will look good, but they will show up as different fonts to the user (normal users hate this) unless the program contains code to find all the fonts of a family and group them together. Fonts like bitstream or helvetica have bold/italy in different ttf files, but they only show as single entries, respectively. That's what I mean build-in. :) This is the best one I think, but this is not for CJK fonts. Single regional CJK fonts usually are as large as ~5MB. Cross regional fonts can be 10~20MB or even more. It's not very practical to have several fonts installed on a device with limited storage. So for most of the case, we relies on font renderer to generate fake bold/italy version of fonts. So I guess nobody ever makes a Chinese font in two versions, bold and normal? Right, no. This can be done with true type fonts as long as the renderer can predict the name of one style from the name of the other style. This is the same problem as western fonts have with bold. This can be easily done with fontconfig customized rules. Suppose I have these fonts: Foo Roman Foo Bold Foo BoldItalic Foo Italic (Foo is the family name, the other part is the face name) That would be in 4 font files. The app can show that to the user as one font choice. If the user asks for italic, the app will switch to using the Foo Italic font file. Suppose I have these: Bar Roman Bar Bold Here, the app will make a fake italic font from Bar Roman and a fake bold-italic font from Bar Bold. This is already done in freetype and fontconfig for CJK fonts with the notable patch sets from Firefly. The same works for Chinese as long as the family names are predictable. Example: Baz Mingti Baz Kaiti Baz Heiti Baz Yuanti Baz Fangsongti That appears to be a 5-way choice. We actually view them as different type faces and use them separately and let the font renderer do the fake bold/italy. This is because it's not necessarily the font vendors provide all these 5 choices. (mostly far more) Not all users install the same choices. Art workers may needs them all, but not for normal users. I'd like to re-pack a CJK font and push it into XO repository once Arne's work is done. That's my current plan. -- Best regards, Yuan Chao ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar's fonts
On Sep 30, 2007, at 16:23 , Yuan Chao wrote: On 9/30/07, Walter Bender [EMAIL PROTECTED] wrote: The problem with serifs is that they often should be smaller than a pixel for typical screen and font sizes. Well, that is Sure. But only in reflective mono mode. Anti-aliasing, which Linux/Pango/Cairo (hence the XO) readily supports, lets you do sub-pixel positioning of elements; I made a Sub-pixel anti-alias rendering is provided by freetype w/o Pango/Cairo since at least Redhat 8 if I remember correctly. However, it won't increase the vertical resolution which is more important on serif fonts that have thinner horizontal strokes than vertical ones. The XO display does not have sub-pixels. Vertical resolution is the same as horizontal, 200 dpi. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar's fonts
Sorry forgot to include [EMAIL PROTECTED] On 9/29/07, Yuan Chao [EMAIL PROTECTED] wrote: On 9/29/07, Albert Cahalan [EMAIL PROTECTED] wrote: You can try to view google news Taiwan edition to test. The current It looks unreadable to me, which is normal for Chinese. :-) I can't seem to find a font size that will make it readable. Indeed, the problem is that the strokes of this font (serif typeface) is simply too thin for XO. (for its high res. and special pixel layout) It helps if you change to reflect screen mode. A free sans-serif typeface is needed for better readability. This is what Arne is working on: a free hei-ti (black) type face truetype font. font size in web activity is ok to me. But the performance needs to be much more improved. Font glyph caching is probably disabled for CJK. I know I've seen that in one of the common libraries. (don't remember: Pango, SDL_ttf, FreeType, etc.) AFAIK, the current lib. used in Web activity is Pango that uses cairo to render the fonts. To have better performance, up to 256 glyphs are cached. However, this is far too few for CJK environment. A typical case for traditional Chinese, there are around 6000 daily used characters, ~3000 for simplified Chinese and ~2000 for Japanese Kanji. (of course they won't show up at the same time on every pages.) An ideal way to handle this is to let bottom layer lib. (freetype, x11) to handle the font rendering which is the which is the way used prior Fedora Core 5. (I'm not an expert here.) With something like 3 characters, glyph caching eats up lots of memory. Perhaps there is a cache size Surely they should not all be cached. The present font cache seems to be just a walk-around instead of a real solution to me. The current web activity even sometimes encounter bad performance on western contents. The problem with serifs is that they often should be smaller than a pixel for typical screen and font sizes. Well, that is not generally possible, so one gets serifs that are way too big. The extra resolution of the XO might make serifs more desirable than they would be on regular PC hardware. Sure. But only in reflective mono mode. For Chinese, so called black face is the corresponding one to sans face. However, the current available (free) one is not very complete. What about the whole bold/italic/underline issue? I guess you have bold. Italic and underline could be used, but aren't the norm AFAIK. (really weird if you go vertical) Would you want endcaps (square/round) to be adjustable? Yes, I can use bold/italic/underline, but they are not standard Chinese way of writing. :) The bold/italic/underline effect of Chinese characters is available till very late. For certain softwares we even need some special patches. And surely no for vertical way of writings. The endcaps you mean is for the end of strokes? They are actually refer to two type faces: square - hei-ti (black), round - yuan-ti. Arne's WIP fonts will provide both as they are based on a existing stroke based database. However, some manual fine tunings are still necessary. That's why it takes time and the work can hardly be shared in order to have a unified result. Line-to-line spacing is an issue when moving the eyes from the end of one line to the beginning of the next. I've seen kids have trouble with this. Big letters increase line-to-line spacing as a side effect; one could instead just increase the line-to-line spacing. So I'm suggesting that one distinguish line-to-line spacing from character height in testing. Excessive line length probably also makes things more difficult because the eye must travel more to get back to the beginning of a line. That's also a good way to try. I don't know how it affects Chinese reading as we have one character for one word. Surely more clear strokes help on reading. Maybe that's why the new vista gothic (black) type face for Japanese is called Meiryo which means clear to understand. -- Best regards, Yuan Chao -- Best regards, Yuan Chao ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar's fonts too small even for fully-sighted people
On Sep 28, 2007, at 9:51 , Zarro Boogs per Child wrote: Ticket URL: https://dev.laptop.org/ticket/3221#comment:6 I wonder if comparative studies have been made with the XO screen? My gut feeling is that it is more comparable to paper-based text books than CRTs. Now Colbert says gut feeling is all you need, but maybe some research is still in order. I found this overview of research articles about Accessible Instructional Materials: http://nimas.cast.org/downloads/nimas_anno_research-2005-07-15.doc (see below for an excerpt for those who can't read .doc) by Nicole Strangman of NIMAS Centers, which incidentally is just 15 mi north of Boston ... Apparently there is more research about children with learning disabilities than about normal kids, but what helps those children can't be bad for others, right? - Bert - Hughes, L. E., Wilkins, A. J. (2000). Typography in children's reading schemes may be suboptimal: Evidence from measures of reading rate. Journal of Research in Reading, 23(3), 314. This study investigated the effect of text size and spacing on the reading speed and accuracy of children age five to eleven. Reading accuracy was significantly higher with large versus small text size. There was a similar direct relationship between reading speed and text size for children five to seven years old. Fuchs, L. S., Fuchs, D. (2000). Using objective data sources to enhance teacher judgments about test accommodations. Exceptional Children, 67(1), 67. This quantitative research study compared the overall test performance of students with and without learning disabilities under standard conditions and with each of three accommodations: extended time, large print, and read aloud. Large print test accommodations significantly improved the overall test performance for students with and without learning disabilities. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar's fonts
I agree that the DejaVu fonts are far from optimal. There are some instructive comments on the wiki about seemingly mundane things like the shape of the 4, etc. While we certainly will have a mechanism for varying the basic system font and size, for the most the activities where the majority of reading is expected to take place have mechanisms for scaling already (Read and Write). The interface in the browser is not yet exposed and Etoys is a place where we expect children to spend time reading and writing as well. That said, I'm not sure that we'll find one set of metrics for all activities and all children from running field tests. But we could be better informed about some of the default settings. -walter On 9/28/07, Albert Cahalan [EMAIL PROTECTED] wrote: Bert Freudenberg writes: I wonder if comparative studies have been made with the XO screen? My gut feeling is that it is more comparable to paper-based text books than CRTs. Now Colbert says gut feeling is all you need, but maybe some research is still in order. Let's do it. Everybody with an XO can find at least a few kids. We need some images of text, and a way to display them on all XOs. (B2-1 hardware too, which normally runs build 406) We'll need several languages. One of the CJK languages would be particularly good to have; at one point Tux Paint had to localize the font size for Japanese if I remember right. Let's try several fonts. I find DejaVu to be somewhat difficult to read because of the non-standard shapes. DejaVu appears to be much worse for the African hooked characters, with defective line widths. Reading speed and accuracy seem like the right metrics. Both black-on-white and white-on-black should be tested. Mono mode in very bright sunlight should be tested. Consider line-to-line spacing separately. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender One Laptop per Child http://laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Sugar's fonts
Bert Freudenberg writes: I wonder if comparative studies have been made with the XO screen? My gut feeling is that it is more comparable to paper-based text books than CRTs. Now Colbert says gut feeling is all you need, but maybe some research is still in order. Let's do it. Everybody with an XO can find at least a few kids. We need some images of text, and a way to display them on all XOs. (B2-1 hardware too, which normally runs build 406) We'll need several languages. One of the CJK languages would be particularly good to have; at one point Tux Paint had to localize the font size for Japanese if I remember right. Let's try several fonts. I find DejaVu to be somewhat difficult to read because of the non-standard shapes. DejaVu appears to be much worse for the African hooked characters, with defective line widths. Reading speed and accuracy seem like the right metrics. Both black-on-white and white-on-black should be tested. Mono mode in very bright sunlight should be tested. Consider line-to-line spacing separately. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
