This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Editorial We have a number of page elements in the FTTF language document that spill over the right margin at 800x600 and (realizing that printers vary) where information is lost when printed. They are: 2.1 Processing Model --the image 3.3 FTIgnore Option --the lines 3 and 6 of the XML fragment in the grey box at the end 4.2.1.2 Examples --the 3rd/last AllMatches image 4.2.2.2 The evaluate Function --the 14th line of the semantics for fts:evaluate in the grey box 4.2.2.6 FTAnd --the 3rd/last AllMatches image 4.2.2.9 FTOrder --all the AllMatches images 4.2.2.10 FTScope --the AllMatches image 4.2.2.13 FTWindow --the 23rd and 24th line of the semantics of window N words in the grey box --the 23rd and 24th line of the semantics of window N sentences in the grey box --the 23rd and 24th line of the semantics of window N paragraphs in the grey box 4.2.2.14 FTTimes --the 7th line of semantics for the general case in the grey box 4.2.3 Match Options Semantics --the 16th line in the schema in the grey box 4.3.3 Example Step 2.3 --the AllMatches image Appendix E.1 --the schema (multiple lines) Appendix E.2 --the stylesheet (multiple lines) Appendix E.3.1.2 --the solution in FT XQueryX (multiple lines) Appendix E.3.1.3 --the 12th and 20th line of the transformation function
(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.
The Task Force concluded that the remaining unfixed instances cited in the original comment were not of sufficient importance to leave this bug open. Experiments with scaling the figures were not very successful. I am marking this bug as FIXED (which is mostly accurate) and then CLOSED>