Frankly, a Wiki can't hurt. Wikis are great ways to document research progress that hasn't made its way into code yet, and helps ensure starting places for new developers.
-----Original Message----- From: Victor Mote [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 12:36 PM To: [EMAIL PROTECTED] Subject: RE: source for hz algorithm FYI, I received the Seybold Report on Publishing Systems (Vol 22, No. 11) a few days ago & have read the article on hz-program. The article was published in 1993, and is pretty print-oriented. If memory serves, this was before PDF & electronic paper really caught on -- this is important because there are some things that might be implemented in a RIP, that may not be supported in PDF or other file formats. The article shed a little more light on the subject. Basically, there are four components: 1. kf -- kerning on the fly (including hanging punctuation & serifs) 2. Kp or Kr (the second letter is the Greek letter rho) -- optical scaling of fonts 3. Ek -- slightly expands or condenses individual character widths to reduce the need for word spacing 4. jp -- justification per paragraph. This is the part that is based on TeX. The problems with kerning on the fly (ie. computing kerning instead of looking it up in a table) are interesting. The article cited the example of a "C" swallowing a "-" that followed it. It seems like what is needed is a way to designate in the font an optical boundary for a character. For example, the capital C might look (approximately) like this: /-----. | . | . | . | . \-----. where the periods on the right side represent an artificial optical boundary (perhaps it needs to more or less concave). Perhaps the boundary should be at least line/arc segments on the left and right, or I suppose it could be a completely enclosed structure. I don't see anything in the OpenType spec for this, but it seems to me that the information could be computed, although the mathematics might be interesting. I /think/ that much of what Kp did is now built into OpenType fonts -- i.e. intelligent adjustment of stroke weights based on point size. Ek is actually hacking the font shapes. I have seen this or something similar done in FrameMaker, which gives the ability to stretch or condense glyphs on both the horizontal and vertical axes. However, FrameMaker also creates PDFs by generating Postscript code and Distilling it, so perhaps this is done in Postscript & embedded. I will have to look into this further. We have already discussed the jp-type functions some. One real trick here is to find an algorithm that will tie all of this together into a useable state. Should we have yet another wiki to outline all of this? Or is it premature to even discuss it much? Also, perhaps some of it ties in with the wiki on resolution of breaks. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
