Ross Gardler wrote: > Ferdinand Soethe wrote: >> Ross Gardler wrote: >> >> >>> I'll certainly consider switching to a -0 if people want to see this, >>> but I strongly caution against it. In my opinion it undermines the whole >>> purpose of Forrest. >> >> >> It is a slippery slope.
Yes, it is: Semantic/logical vs. presentational/physical markup. See below and http://en.wikipedia.org/wiki/Comparison_of_document_markup_languages#Characteristics >> >> Otoh there are many ways a developer can bend Forrest out of shape so >> why not leave it up to them and their clients to decide. >> >> I guess if it defaults to _not_ carry over styles and the switch carries >> a sufficient warning in place that should be ok. > > Yes, it sounds reasonable. And Thorsten was careful to have a very clear > warning in the contract description. > > However, I'm still concerned of posts to the user list of the form: > > "My section is not appearing in the TOC" > "Everything looks fine in HTML but in PDF sections get all screwed up" > "My headings have an inconsitent format" > etc. "Section" and "Heading" are semantic terms, i.e. we (the users) talk about the meaning of the marked-up text. Not appearing in the TOC e.g. means that they made them *look* like section/heading but did not mark them up correctly. X "looks fine" in Y but not in Z: may mean that Z does not support the notion of X but Y does. What it usually means is that the markup was fine-tuned for the *Look* not the meaning, e.g. "My web page looks fine in MSIE but not in Z". > The potential problems are massive, and since we claim to give a uniform > output from inputs we are in danger of failng to deliver what we claim > to do so. Sure the user should know what is going on, after all there is > a warning in the contract description. But we all know users ignore > things they do not understand and go ahead anyway. It works on the first > test document so they spen time building a full site and then *bang* > half the documents don't work. We run a danger with WYSIWYG-input: users may use presentational markup (bold, 24pt and these things) instead of semantic like "section" and "heading". I always thought of the Word/OOo (and now ODf) is to import "legacy" documents, not to encourage users to write new content. (OK, this is a radical point of view). We have this in some of the plugins, e.g. OOo, Excel. There was a discussion about carrying over "style" from such plugins, see http://marc.theaimsgroup.com/?l=forrest-dev&m=110916000908143&w=2 If we allow "style" to carry through to the result this needs to be implemented in all (!?) output formats Forrest supports (at least users may request it; I requested it once for cell coloring in PDF). As for the Excel-Plugin: I ignored any styling done in Excel (note, I introduced bg-color from the content of the cells). And still, it's just a special-case input vehicle for not-XML- savvy users. Others use a XML editor for "near WYSIWYG" (see http://forrest.apache.org/docs_0_70/catalog.html). To use these input-plugins "correctly" they need good documentation, as e.g. for OOo-HowTo http://tinyurl.com/ooqcw instructing them how to use OOo to write "proper" new documents that work seamlessly with Forrest. What do you think? Johannes > > Ross > -- User Interface Design GmbH Teinacher Str. 38, 71634 Ludwigsburg Fon: +49-7141-37700-0 Fax: +49-7141-37700-99 Email: [EMAIL PROTECTED] Internet: www.uidesign.de Geschäftsstellen: Teinacher Str. 38, 71634 Ludwigsburg Truderinger Str. 330, 81825 München Friedrichsring 46, 68161 Mannheim Buch "User Interface Tuning" von Joachim Machate & Michael Burmester www.user-interface-tuning.de Attraktivität von interaktiven Produkten messen mit www.attrakdiff.de
