David Starner wrote:
On 9/28/05, Lee Passey <lee@novomail.net> wrote:
And this is the problem with PDF. Having a PDF file does not necessarily mean you will get a nice looking printout, it only means you will get a printout that looks like what the document author wanted you to have.
It gives me a better printout than anything else I've seen can.
If you like TEI+XSL ==> PDF ==> print I'd bet you'd like TEI+XSL ==> LaTeX ==> print even better. Perhaps someone will take up the challenge and work on an XSL script for LaTeX. And of course just creating a PDF file in and of itself is not a solution to creating good print output. I've seen PDF files that use the Courier type and 66 character lines, which look almost like typewriter output. Wordpad can produce output better than that. If your preferred end product is print, I'd bet there is a TEI+XSL ==> print solution that would be at least as good, if not better, and would avoid the intermediate PDF phase. On the other hand, very few people have installed XSL script processors, so the advantage of the PDF solution is that you can do the first step on a remotely hosted machine, download the intermediate file, and then print that. Of course, the downside to all these solutions is that you are relying on a third party to create the XSL file, so you are forced to accept whatever stylistic choices the host is offering; this is typically not a problem if (1) the XSL is designed to conform to statistical stylistic norms, and (2) you're relatively tolerant of diveristy in styles. [snip]
And I don't think that "allow[ing] the end user to have the maximum amount of input as to the which rendering decisions are made" is a good idea. Options take time to code, most people don't care about widows and orphans, and a page full of mysterious options (and I suspect widows and orphans fall into that classification for many users) is a way to drive away many users.
Here we will just have to agree to disagree. In my mind, empowering end users is _never_ a bad thing. And while it may be true that most people won't care about widows and orphans, we know that there are at least two people who do (and frankly, if I had a choice between a product that minimized widows and orphans, and one that didn't, I would be inclined to pick the first). Should those people who _do_ care be forced to overcome steep barriers just because they are part of a minority? Now a page full of "mysterious options" can, indeed, be daunting. But the solution is not to make all users suffer the same options, but to create a selection process that is _not_ daunting. I doubt very much that Microsoft Word has lost a lot of users because it allows widow/orphan control; at the same time I doubt if most MSWord users even know that widow/orphan control is possible. That's because it is hidden behind a menu tree that says, in essence, "power users click here; novices should avoid this." I certainly wouldn't suggest that an end user should have to run a gauntlet of choices before he or she can download a file, but I _would_ suggest that s/he should have the option. And I don't think that a page of check boxes is the best solution even then. When I suggested that CSS could solve many of these problems, some have responded that CSS is far to complex to expect an end user to edit a CSS file to change an option. I agree with the statement, I just don't agree with the implied conclusion. I would foresee the typical end user downloading a TEI text, and then downloading a number of CSS files which all claim to be the ultimate expression of sylistic perfection. The end user could try out all of the CSS files by the simple expedient of renaming a candidate file to the standard name (e.g. pgtei.css) and then looking at the output. He or she would then simply stick with the one that reflects his or her preferences the best. Only if the end user could not find an existing CSS file adequate to his/her needs would there be any requirement to tweak a CSS file. And if every PGTEI file contained a stylesheet declaration that included the standard file name, once the decision was made it would never have to be revisted, and no editing of source files would ever be required. Of course, the same sort of solution would work with XSLT, but that would require that every end user have an XSLT processor, and that every file downloaded would have to be converted before use. The way to solve the complexity problem for unsophisticated users is to provide intelligent defaults, not to take away freedom of choice.