[Bug 3647] FT (Editorial) Page elements too wide for display and printing

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3647


jim.melton@acm.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




------- Comment #1 from jim.melton@acm.org  2006-09-09 19:56 -------
(This is a personal response not yet seen by the Task Force.)

I question how much effort we should make in order to make the document more
convenient to read at SVGA (800x600) resolutions.  Most computers and monitors
these days are fully capable of displaying at XGA (1024x768) or better
resolutions.  For those people who prefer the lower SVGA resolution (perhaps
people with some sight impairment), virtually all browsers permit the screen to
be scrolled left and right so that the entire width of (e.g.) an image can be
seen.  I worry that reducing the processing model figure in particular will
make it significantly less readable and comprehensible for the large majority
of our audience.  (Besides, and this is partly tongue in cheek, what about
users who want to use VGA, 640x480 resolution?  Should we also accommodate
them?)

As far as printing goes, I have not encountered a (Windows) printer driver in
years that is incapable of printing in both portrait and landscape
orientations. None of the figures or examples in our spec exceed the width of
normal printing in the landscape orientation.  I cannot dredge up sympathy for
people who insist that their documents have to be printed in portrait
orientation and want consequent changes to the spec that makes it less usable
to the majority of the audience. 

Of course, I agree that any examples or images that can be edited to make them
"narrower" without changing their meaning should be edited thusly. An obvious
example is the XML fragment in section 3.3 FTIgnore Option.  However, I would
object to making changes that have semanatic effect simply to accommodate
people who are unwilling (but not unable) to use higher resolution displays or
landscape mode printing.  (In fairness, I must say that only a few of the
problems identified in this bug would fall into this category; those few
problems are those that would force breaking URLs at artificial boundaries.)

As the individual responsible for most of the images identified in this bug, I
am not happy at the prospect of having to redraw many of them to accommodate a
demand that I consider unreasonable. 

As the individual responsible for the XQueryX material identified in the bug, I
should point out that many of the problems are due to whitespace that I was
unable to explain until recently and have finally fixed; the fixes will appear
in the next internal publication of the FT spec.  (If you want to know, it's
because my XML editing tool was insisting on using tabs for indents; it
"interpreted" a tab to be 2 spaces, while many browsers interpret them to be 8
spaces.  My fix was to teach my editing tool to retain my spaces instead of
substituting tabs.)

Other parts of the XQueryX material can be, and should be, edited to use two or
more lines instead of single (overly) long lines.  I intend to handle those
editorially.

Received on Saturday, 9 September 2006 19:56:50 UTC