> I suggest a small block of new options: > > --font=std,bold,large,largebold,narrow > > If we're moving towards storing the actual font value in the > database itself, why not put a pointer there to specify it upon creation?
I don't think I understand this suggestion, David. The HTML specifies the various fonts; I'm not sure what overriding it on the command line would add. Are you suggesting this just for text files? In that case, I think it would be better to keep them as they are, and allow the user to adjust the UI in the viewer (via the preferences) to select an appropriate font. By the way, just in case anyone's worried, I'm not "gutting" the Python parser :-). I'm just fixing some of the parameter passing to make transferring information more natural, and re-doing the main loop to make it simpler. For example, when we process an image, we might return either one or two PluckerDocs, logically -- if the image is inline and alt_max* is specified and the image has to be scaled, we return both a small version and the larger version. If we move to supporting *really* big images (where I'm heading -- can't live without the Sunday color version of Calvin & Hobbes!), we might get back arbitrarily many PluckerDocs from a single image conversion. I'd like to make the way that parameters are passed support this. For another example, to support the <OBJECT> tag in HTML 4, we need to be able to either recursively pluck HTML, or pluck HTML in stages. This again means that the simple interface provided by our current parsing API is unsufficient. Bill
