From: Jason S. <jsi...@gm...> - 2008-04-09 13:37:35
|
First off, I did some looking and found the CSS property that makes the <pre></pre> element obsolete: white-space:pre; So retaining this formatting in the Web Reports is just a simple matter of defining a new class with at least that CSS rule, maybe a few others (font-family:monospace; probably). On Wed, 2008-04-09 at 08:59 +0200, Benny Malengier wrote: > 1/In the GUI, preformatted check box is replaced with a no-word wrap > check box. It should be obvious what that does. This is only an > application thing. No need to store it in the database (we could for > convenience obviously, but a session wide remembering should suffice). > > 2/A style is added to note toolbar: preformatted. This would result > visually to a mono space font and if possible some other indication it > is not 'just' a font change. (Ideas ?) > Like this, preformatted text is a style, stored like italics and bold, > and it is up to the reports on how to display it: No longer two things > to test in the note editor, no longer two differently behaving notes I'm in pseudo-agreement. It should be that all notes are composed of 'plain text' but either GRAMPS or the Report deals with whether or not there is markup in the plain text. There would be a value in the database that identifies the user's intended formatting. The contents of the note would not be altered by the formatting option chosen. In this way a 'note item' would have two values in the database: 1. The contents of the note 2. The format definition of the note The first value would always be saved as 'plain text'. The second value would tell GRAMPS or the Report how to interpret it. When NarrativeWeb.py is processing a Note: if value 2 says 'Preformatted' it follows the conditional 'if format == preformatted' and dumps the contents into <p class="NotePreformatted"></p> if value 2 says 'Plain Text' it follows the corresponding conditional and dumps the contents into <p></p> Now, if Notes will support 'styling' like bold or italic, then I would suggest having a third format called 'Rich Text' or 'Styled Text'. If GRAMPS provides a WYSIWYG editor, this value would tell it to display the styling in the Note contents appropriately. The 'Styled Text' editor will probably have to allow for paragraphs and so Narrative Web wouldn't dump a 'Styled Text' Note into a <p></p> element, but maybe a <div></div> element instead to allow for the user's own paragraph elements. I think this approach is best because the chosen format does not add to or alter the plain text contents of the note itself. This way a user can learn the effects of the different formats through trial and error without altering the contents of their note. A setting like this should not add to or alter the contents of the note. > So, at a minimum the report generators must do something, eg: > * In website output, it makes sense to use the <pre> tag > * In latex I suppose \begin{verbatim} > * ... Exactly. Well, except for that bit about adding the <pre> element to the Note contents, but I think you get what I'm saying. > Quite some work, and a database upgrade to change preformatted notes, > but I believe the above is a streamlining of the system, reducing the > present two systems to one way of doing things. Perhaps > 'verbatim' (http://en.wikipedia.org/wiki/Verbatim) is also a nicer > style indication than 'preformatted' I propose using 'Simple', 'Preformatted' and 'Styled'. You might be right about 'verbatim', but whatever you call it, I think having a brief description on 'hover' or visible somewhere in the interface would be very helpful. On the other hand, making it so that GRAMPS changes the visual appearance of the note according to the chosen format value would also help make it clear. So, maybe 'Preformatted' is displayed in the editor with a monospace font while 'Simple' is displayed in a sans-serif. I guess 'Styled' would look the same as 'Simple', except that there would be text-styling tools/options available above the input box. -Jason |