From: Benny M. <ben...@gm...> - 2008-04-09 06:58:54
|
Let me do a suggestion about how to change the preformatted notes in GRAMPS. First, people use them for various reasons. Most specifically, people do them in GRAMPS because like that they are inline in the application and reports (not the case with media files you can even search on them in GRAMPS), and secondly, they need the hand formatting for reading purposes of the note (especially when printed) and this does not only mean columns. What is preformatted note now: 1/visually in GUI, it means that word wrap is switched off 2/visually in reports: it is a style where formatting is kept as written down in the note (same spaces, same tabs, ...) Suggestion: Why not split the two functions? So: 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 The reports then have to interpret style tags of the notes as we see fit. With above change, we will be forced to do that at a minimum for the preformatted style so as not to loose functionality as opposed to the present version. This is not necessarily a bad thing, as it will force us to think of a good way to replace style tags for the report generators. With styled text, if the style is not in the oppenoffice document, the first user remark will be: I do not see the style in the document. 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} * ... 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' Ideas, remarks? Benny 2008/4/9, James G. Sack (jim) <jg...@sa...>: > > I've cut all the quotes because I just want to make a general comment, > and report what I gathered at the end. Not that my summary is complete, > best, or final, of course. Others may certainly wish to reply. > > ==> I think this thread has been a great exchange. > > I thought Jason made an excellent point that if presentation or even > layout is more than just a little important, then it may be not be best > practice to try to transcribe it into a note -- it would be worth > considering referencing it as a source in a better (media) format. > > Benny's example and Doug's appeal not to make simple conveniences > difficult lead me to believe that support for simple tabular data would > be a shame to forgo. > > Brian's reminder to be sensitive to archival disadvantages of > proprietary formats is well taken. Maybe there's a future for additional > extensions dealing with this issue. Maybe such tools can usefully extend > the level of complexity, and let users decide. The use of _future_ and > _extension_ would be key, I suppose. (Ok this is not a recap -- sorry). > > I also liked Jason's afterthought that respect for good old fashioned > ASCII text should maybe be replaced with respect for plain text. I think > we can drop the "ASCII" modfier and still adequately emphasize the text > benefits without snubbing languages for which the 95 ASCII characters > are inadequate. > > I especially liked Doug's remark hoping that we can find the right > balance -- that, after all, is the right recipe in many cases, is it not? > > Cheers to all, > > ..jim > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
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 |
From: Benny M. <ben...@gm...> - 2008-04-09 13:52:46
|
2008/4/9, Jason Simanek <jsi...@gm...>: > > 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). nice 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. Jason, I think you should check out the trunk code in svn. You will see notes with styling: bold, font color, font selection, background color, .... . I agree largely to what you say, however, the discussion of what you see in GRAMPS as opposed to what you see in a report (be it the web report or odf) should be kept separate as much as possible. It confuses things, as you run the risk of coding the interface for a specific report, whereas the limitations of one, should not hinder the other. In the 3.1.x code in trunk, we indeed have the contents of a note in one field, and format definition in another, but more complex than the basic styling you mention, in that the format defiitions is like: character 8 to 10 is italics, character 124 to 139 is bold, ... (I did not follow the code, but this is how I understood the original design). This is then interpreted to the screen, and every report backend will need to interpret it in it's own way. The advantage of this system is that we do not need to strip styling from the text for reports that do not know what to do with it. The report can just show the plain text without the formatting without any parsing required. Benny > 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 > > |
From: David M. <mar...@gm...> - 2008-04-09 18:41:34
|
I did my taxes last night and missed a lot of this discussion, so let me take a few steps back... On 4/8/08, Jason Simanek <jsi...@gm...> wrote: > > > Seriously, the example I'm looking at would be better off as a > > > separate Word Processor document converted into PDF and then > > > added as a Media Object. > > You lost me at "converted into PDF." I would fully agree with this > > point if you said RTF or any other form of formatted text, but a > > static image of formatted text would be very cumbersome and > > unfriendly. > > First, PDF is not a static image of formatted text. PDF is a complex > file format containing text and image content whose layout/presentation > is held intact independent of the resources available on any machine > that views it. Fonts can also be embedded so that regardless of the > recipient's font selection, the document appears as you originally > created it. PDFs can also contain bookmarks, indexes, hyperlinks and > meta information. The text content can also be searched. > > RTF, Simple Text and ODF are excellent formats also. However, since we > are discussing a situation where retaining the formatting/presentation > of a text document is the important characteristic, I think PDF fulfills > that demand most completely. Wherever or whenever it is viewed it will > always look the same. OK, I misspoke when I said "static image", but my intended emphasis was on the "cumbersome and unfriendly" aspect of using PDF media objects in web reports. Maybe I'm missing something, but wouldn't this just put a link to a separate file in the Gallery section for a person? That is entirely contrary to the intent of the narrative report, and non-intuitive for the end report viewer--most would never see it. Even if this PDF were somehow embedded in the narrative, it would be very cumbersome--especially if it were a mult-page document. I just don't see how a PDF could ever accomplish what (I think) is desired here... On 4/7/08, Benny Malengier <ben...@gm...> wrote: > ...in 3.0.0 you have multiple notes, so you could split this up... Benny made an excellent point here for the case of seamlessly adding a preformatted section (such as a census record or the "signature section" of a will) to a mostly unformatted narrative. This seems simple and intuitive. However, I suggest that you remove the "Narrative" header from subsequent notes. Currently, this header is included once per note used on individual pages (i.e. if I add 3 notes to one person, that person's page has 3 separated Narrative sections.) On 4/8/08, Brian Matherly <br...@gr...> wrote: > Notes should be reserved to used as just that: > "NOTES". They are not a good tool to be used for > narratives, biographies, articles or dissertations. ...which is precisely the problem that leads users like me to misuse (abuse?) the system to get our narratives, biographies, articles, or dissertations into our GRAMPS-generated reports. GRAMPS is our database/interface, and the reports it generates are the only way we can share our research with others. My goal is to present all of my research in an attractive, comprehensive, intuitive report that my father--or even my computer-illiterate grandmother--could navigate with ease. I have even gone to extremes on a few notes to include entire formatted essays. For example: http://home.comcast.net/~davidmartin/ppl/a/b/ab444345c8025b59bdf.html I would gladly forgo hacking at notes to make them look like this if there were another way to have my research presented attractively in GRAMPS reports. As I guess you can tell, the butchering I did to this note renders any *other* GRAMPS text report useless. I have been eagerly awaiting Formatted Notes to allow me to generate attractive text reports for print as well as HTML for web... On 4/9/08, Jason Simanek <jsi...@gm...> wrote: > 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. I second that! This is *exactly* what I have been waiting for. I don't even care about the WYSIWYG editor, but I'm sure other users would appreciate one... David On 4/9/08, Benny Malengier <ben...@gm...> wrote: > > > 2008/4/9, Jason Simanek <jsi...@gm...>: > > 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). > > nice > > > 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. > > Jason, I think you should check out the trunk code in svn. You will see > notes with styling: bold, font color, font selection, background color, .... > . > I agree largely to what you say, however, the discussion of what you see in > GRAMPS as opposed to what you see in a report (be it the web report or odf) > should be kept separate as much as possible. It confuses things, as you run > the risk of coding the interface for a specific report, whereas the > limitations of one, should not hinder the other. > > In the 3.1.x code in trunk, we indeed have the contents of a note in one > field, and format definition in another, but more complex than the basic > styling you mention, in that the format defiitions is like: character 8 to > 10 is italics, character 124 to 139 is bold, ... (I did not follow the code, > but this is how I understood the original design). This is then interpreted > to the screen, and every report backend will need to interpret it in it's > own way. The advantage of this system is that we do not need to strip > styling from the text for reports that do not know what to do with it. The > report can just show the plain text without the formatting without any > parsing required. > > Benny > > > 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 > > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: Zsolt F. <zso...@gm...> - 2008-04-09 22:09:03
|
Benny, On Wed, 9 Apr 2008 08:59:01 +0200 "Benny Malengier" <ben...@gm...> wrote: > Let me do a suggestion about how to change the preformatted notes in > GRAMPS. > > > First, people use them for various reasons. Most specifically, people > do them in GRAMPS because like that they are inline in the > application and reports (not the case with media files you can even > search on them in GRAMPS), and secondly, they need the hand > formatting for reading purposes of the note (especially when printed) > and this does not only mean columns. Noted. > What is preformatted note now: > > 1/visually in GUI, it means that word wrap is switched off > 2/visually in reports: it is a style where formatting is kept as > written down in the note (same spaces, same tabs, ...) We all know it, only for completeness: in both cases also a mono space font should be used. > Suggestion: Why not split the two functions? So: I think splitting the two issues was always the idea, except that we wanted a way for storing the styled notes, which will make our life easier when we get to the reports. > 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). Makes sense. > 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 ?) What exactly would the preformatted toolbar do? a. add a monospace font face tag to the whole range of the note; b. add a new 'preformatted' tag to the whole range of the note? In case of a) I don't see difference from telling the users: 'if you want preformatted note, clear the word wrap box, and set the whole text to mono space font!' However, the existing convenient preformatted checkbox could do the same thing with only one click. In case of b) we would mix up things a bit. StyledText is a concept of having character based style formatting of a string. A note being preformatted or verbatim is not a character style, but a combination of character styles applied to the whole string. Also the StyledTextBuffer implementation would become uglier. Now each StyledText formatting tag is translated to a gtk.TextTag, and vice-verse. There is a one to one relation. While introducing 'special' tags e.g. the gtk.TextTag - StyledTextTag conversion routine will have to watch for other things besides gtk.TextTags coming from the buffer (i.e. state of the toolbar or a flag). I'm not sure I like the idea. > 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 This would only move the complications from the note editor into the text buffer, as above. [snip] > Ideas, remarks? I'm probably missing something, but what is the problem with the preformatted checkbox and the flag in the notes? Zsolt |
From: Benny M. <ben...@gm...> - 2008-04-10 07:15:59
|
2008/4/10, Zsolt Foldvari <zso...@gm...>: > > [snip] > > > What is preformatted note now: > > > > 1/visually in GUI, it means that word wrap is switched off > > 2/visually in reports: it is a style where formatting is kept as > > written down in the note (same spaces, same tabs, ...) > > > We all know it, only for completeness: in both cases also a mono space > font should be used. indeed > Suggestion: Why not split the two functions? So: > > > I think splitting the two issues was always the idea, except that we > wanted a way for storing the styled notes, which will make our life > easier when we get to the reports. > > > > 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). > > > Makes sense. > > > > 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 ?) > > > What exactly would the preformatted toolbar do? > a. add a monospace font face tag to the whole range of the note; > b. add a new 'preformatted' tag to the whole range of the note? I mean just a preformatted icon on the toolbar. What it would do is set the selection to preformatted, just the same way as bold. So not neccessarily the entire note. You would be able to mix preformatted text with normal text. The difference between preformatted and normal is essentially: 1/ monospace font 2/ spaces, tabs, line breaks are verbatim in the report that prints them. Essentially, it is only needed for those reports that remove whitespace automatically, to let them know not to do that (html, latex), to use mono font, not to do automatic word wrapping in the report (doc, ... not sure those can do that). In case of a) I don't see difference from telling the users: 'if you > want preformatted note, clear the word wrap box, and set the whole text > to mono space font!' However, the existing convenient preformatted > checkbox could do the same thing with only one click. The difference here is that you can mix preformatted and formatted. Now we have a black and white world. I understand the problems however, if somebody sets a different font in the preformatted piece, essentially this can be stored by us, but a report will not be able to handle it (note that you can do this in trunk on a preformatted note, perhaps toolbar must be disabled, but then switching it on off on removes tags?? I don't mind bold/italics in preformatted, but changing font is counter to what is meant...). In case of b) we would mix up things a bit. StyledText is a concept of > having character based style formatting of a string. A note being > preformatted or verbatim is not a character style, but a combination of > character styles applied to the whole string. > Also the StyledTextBuffer implementation would become uglier. Now each > StyledText formatting tag is translated to a gtk.TextTag, and > vice-verse. There is a one to one relation. While introducing 'special' > tags e.g. the gtk.TextTag - StyledTextTag conversion routine will have > to watch for other things besides gtk.TextTags coming from the buffer > (i.e. state of the toolbar or a flag). > I'm not sure I like the idea. Preformatted, would that not translate to mono space font, and eg the special character view in the old word processors (you see a tab as a symbol, a space as a symbol, and a newline as a symbol). Obviously, if things do not simplify by changing preformatted, it has no use to do it. > 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 > > > This would only move the complications from the note editor into the > text buffer, as above. > > [snip] > > > Ideas, remarks? > > I'm probably missing something, but what is the problem with the > preformatted checkbox and the flag in the notes? The problem as I see it: 1/do we need two things? Can we not simplify the GUI? 2/one can not mix preformatted with normal text. (small inconvenience only?) 3/all report generators will have to parse tags. They also need two blocs, one for preformatted, one for normal. Having only one note with a tags, means they have one single way of parsing the tags. Benny |
From: Benny M. <ben...@gm...> - 2008-04-10 07:33:45
|
2008/4/10, Benny Malengier <ben...@gm...>: > > > > 2008/4/10, Zsolt Foldvari <zso...@gm...>: > > > > [snip] > > > > > What is preformatted note now: > > > > > > 1/visually in GUI, it means that word wrap is switched off > > > 2/visually in reports: it is a style where formatting is kept as > > > written down in the note (same spaces, same tabs, ...) > > > > > > We all know it, only for completeness: in both cases also a mono space > > font should be used. > > > indeed > > > Suggestion: Why not split the two functions? So: > > > > > > I think splitting the two issues was always the idea, except that we > > wanted a way for storing the styled notes, which will make our life > > easier when we get to the reports. > > > > > > > 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). > > > > > > Makes sense. > > > > > > > 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 ?) > > > > > > What exactly would the preformatted toolbar do? > > a. add a monospace font face tag to the whole range of the note; > > b. add a new 'preformatted' tag to the whole range of the note? > > > I mean just a preformatted icon on the toolbar. What it would do is set > the selection to preformatted, just the same way as bold. So not > neccessarily the entire note. You would be able to mix preformatted text > with normal text. > > The difference between preformatted and normal is essentially: > 1/ monospace font > 2/ spaces, tabs, line breaks are verbatim in the report that prints them. > > Essentially, it is only needed for those reports that remove whitespace > automatically, to let them know not to do that (html, latex), to use mono > font, not to do automatic word wrapping in the report (doc, ... not sure > those can do that). > > > In case of a) I don't see difference from telling the users: 'if you > > want preformatted note, clear the word wrap box, and set the whole text > > to mono space font!' However, the existing convenient preformatted > > checkbox could do the same thing with only one click. > > > The difference here is that you can mix preformatted and formatted. Now we > have a black and white world. I understand the problems however, if somebody > sets a different font in the preformatted piece, essentially this can be > stored by us, but a report will not be able to handle it (note that you can > do this in trunk on a preformatted note, perhaps toolbar must be disabled, > but then switching it on off on removes tags?? I don't mind bold/italics in > preformatted, but changing font is counter to what is meant...). > About a preformatted icon. I was in the expression it would be exclusive, not allowing italics, .... But I see html can do those things while in preformatted mode, it sufficies to have mono space font. So I guess we should really define what styling preformatted can have and what not. And I suppose we just cannot allow to have font changed when preformatted, the rest is still possible? It has no use to allow certain styling in the GUI in the preformatted notes, if the reports will never be able to show it. Note that there are some weird things now in editing. Eg, set a piece of text to bold, then click the font icon, and change font, set it too regular. After this, the text is still bold due to the setting of the bold. If bold and italic are in the font chooser, they should change the setting, and perhaps be preselected when font dialog opens (if not two settings in the piece of text)? Only a minor thing. In case of b) we would mix up things a bit. StyledText is a concept of > > having character based style formatting of a string. A note being > > preformatted or verbatim is not a character style, but a combination of > > character styles applied to the whole string. > > Also the StyledTextBuffer implementation would become uglier. Now each > > StyledText formatting tag is translated to a gtk.TextTag, and > > vice-verse. There is a one to one relation. While introducing 'special' > > tags e.g. the gtk.TextTag - StyledTextTag conversion routine will have > > to watch for other things besides gtk.TextTags coming from the buffer > > (i.e. state of the toolbar or a flag). > > I'm not sure I like the idea. > > > Preformatted, would that not translate to mono space font, and eg the > special character view in the old word processors (you see a tab as a > symbol, a space as a symbol, and a newline as a symbol). > Obviously, if things do not simplify by changing preformatted, it has no > use to do it. > > > 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 > > > > > > This would only move the complications from the note editor into the > > text buffer, as above. > > > > [snip] > > > > > Ideas, remarks? > > > > I'm probably missing something, but what is the problem with the > > preformatted checkbox and the flag in the notes? > > > The problem as I see it: > 1/do we need two things? Can we not simplify the GUI? > 2/one can not mix preformatted with normal text. (small inconvenience > only?) > 3/all report generators will have to parse tags. They also need two blocs, > one for preformatted, one for normal. Having only one note with a tags, > means they have one single way of parsing the tags. > > > > Benny > > |
From: Benny M. <ben...@gm...> - 2008-04-10 11:49:05
|
Just a note, I notice that wx has a very nice textview used in many products: stc (eg http://www.wxpython.org/docs/api/wx.stc.StyledTextCtrl-class.html#SetViewWhiteSpace). So what they do must be possible in GTK, but I do not see things in the GTK reference to show eg whitespace with texttags. Indeed, the StyledTextCtrl class ;-) Benny 2008/4/10, Benny Malengier <ben...@gm...>: > > > > 2008/4/10, Benny Malengier <ben...@gm...>: > > > > > > > > 2008/4/10, Zsolt Foldvari <zso...@gm...>: > > > > > > [snip] > > > > > > > What is preformatted note now: > > > > > > > > 1/visually in GUI, it means that word wrap is switched off > > > > 2/visually in reports: it is a style where formatting is kept as > > > > written down in the note (same spaces, same tabs, ...) > > > > > > > > > We all know it, only for completeness: in both cases also a mono space > > > font should be used. > > > > > > indeed > > > > > Suggestion: Why not split the two functions? So: > > > > > > > > > I think splitting the two issues was always the idea, except that we > > > wanted a way for storing the styled notes, which will make our life > > > easier when we get to the reports. > > > > > > > > > > 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). > > > > > > > > > Makes sense. > > > > > > > > > > 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 ?) > > > > > > > > > What exactly would the preformatted toolbar do? > > > a. add a monospace font face tag to the whole range of the note; > > > b. add a new 'preformatted' tag to the whole range of the note? > > > > > > I mean just a preformatted icon on the toolbar. What it would do is set > > the selection to preformatted, just the same way as bold. So not > > neccessarily the entire note. You would be able to mix preformatted text > > with normal text. > > > > The difference between preformatted and normal is essentially: > > 1/ monospace font > > 2/ spaces, tabs, line breaks are verbatim in the report that prints > > them. > > > > Essentially, it is only needed for those reports that remove whitespace > > automatically, to let them know not to do that (html, latex), to use mono > > font, not to do automatic word wrapping in the report (doc, ... not sure > > those can do that). > > > > > > In case of a) I don't see difference from telling the users: 'if you > > > want preformatted note, clear the word wrap box, and set the whole > > > text > > > to mono space font!' However, the existing convenient preformatted > > > checkbox could do the same thing with only one click. > > > > > > The difference here is that you can mix preformatted and formatted. Now > > we have a black and white world. I understand the problems however, if > > somebody sets a different font in the preformatted piece, essentially this > > can be stored by us, but a report will not be able to handle it (note that > > you can do this in trunk on a preformatted note, perhaps toolbar must be > > disabled, but then switching it on off on removes tags?? I don't mind > > bold/italics in preformatted, but changing font is counter to what is > > meant...). > > > > About a preformatted icon. I was in the expression it would be exclusive, > not allowing italics, .... But I see html can do those things while in > preformatted mode, it sufficies to have mono space font. > So I guess we should really define what styling preformatted can have and > what not. And I suppose we just cannot allow to have font changed when > preformatted, the rest is still possible? It has no use to allow certain > styling in the GUI in the preformatted notes, if the reports will never be > able to show it. > > Note that there are some weird things now in editing. Eg, set a piece of > text to bold, then click the font icon, and change font, set it too regular. > After this, the text is still bold due to the setting of the bold. If bold > and italic are in the font chooser, they should change the setting, and > perhaps be preselected when font dialog opens (if not two settings in the > piece of text)? Only a minor thing. > > In case of b) we would mix up things a bit. StyledText is a concept of > > > having character based style formatting of a string. A note being > > > preformatted or verbatim is not a character style, but a combination > > > of > > > character styles applied to the whole string. > > > Also the StyledTextBuffer implementation would become uglier. Now each > > > StyledText formatting tag is translated to a gtk.TextTag, and > > > vice-verse. There is a one to one relation. While introducing > > > 'special' > > > tags e.g. the gtk.TextTag - StyledTextTag conversion routine will have > > > to watch for other things besides gtk.TextTags coming from the buffer > > > (i.e. state of the toolbar or a flag). > > > I'm not sure I like the idea. > > > > > > Preformatted, would that not translate to mono space font, and eg the > > special character view in the old word processors (you see a tab as a > > symbol, a space as a symbol, and a newline as a symbol). > > Obviously, if things do not simplify by changing preformatted, it has no > > use to do it. > > > > > 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 > > > > > > > > > This would only move the complications from the note editor into the > > > text buffer, as above. > > > > > > [snip] > > > > > > > Ideas, remarks? > > > > > > I'm probably missing something, but what is the problem with the > > > preformatted checkbox and the flag in the notes? > > > > > > The problem as I see it: > > 1/do we need two things? Can we not simplify the GUI? > > 2/one can not mix preformatted with normal text. (small inconvenience > > only?) > > 3/all report generators will have to parse tags. They also need two > > blocs, one for preformatted, one for normal. Having only one note with a > > tags, means they have one single way of parsing the tags. > > > > > > > > Benny > > > > > |
From: Zsolt F. <zso...@gm...> - 2008-04-10 20:48:11
|
On Thu, 10 Apr 2008 13:49:08 +0200 "Benny Malengier" <ben...@gm...> wrote: > Just a note, I notice that wx has a very nice textview used in many > products: stc (eg > http://www.wxpython.org/docs/api/wx.stc.StyledTextCtrl-class.html#SetViewWhiteSpace). > So what they do must be possible in GTK, but I do not see things in > the GTK reference to show eg whitespace with texttags. > > Indeed, the StyledTextCtrl class ;-) They do it with code for sure and not with a simple texttag. There is also GtkSourceView [1], which has Python binding too [2]. Though I don't know if it supports showing whitespace characters. I'll check the code of both. Zsolt [1] http://gtksourceview.sourceforge.net/downloads.html [2] http://ftp.gnome.org/pub/GNOME/sources/pygtksourceview/2.1/ |
From: Zsolt F. <zso...@gm...> - 2008-04-10 20:36:23
|
On Thu, 10 Apr 2008 09:33:49 +0200 "Benny Malengier" <ben...@gm...> wrote: > Note that there are some weird things now in editing. Eg, set a piece > of text to bold, then click the font icon, and change font, set it > too regular. After this, the text is still bold due to the setting of > the bold. If bold and italic are in the font chooser, they should > change the setting, and perhaps be preselected when font dialog opens > (if not two settings in the piece of text)? Only a minor thing. Nice, I never thought about this before. I think I prefer to define a custom font selector without the style treeview to make life easier. Zsolt |
From: zsolt f. <zso...@gm...> - 2008-04-11 10:32:55
|
On 4/10/08, Zsolt Foldvari <zso...@gm...> wrote: > On Thu, 10 Apr 2008 09:33:49 +0200 > "Benny Malengier" <ben...@gm...> wrote: > > > Note that there are some weird things now in editing. Eg, set a piece > > of text to bold, then click the font icon, and change font, set it > > too regular. After this, the text is still bold due to the setting of > > the bold. If bold and italic are in the font chooser, they should > > change the setting, and perhaps be preselected when font dialog opens > > (if not two settings in the piece of text)? Only a minor thing. > > > Nice, I never thought about this before. I think I prefer to define > a custom font selector without the style treeview to make life easier. In r10547 there a workaround. I think this is the easiest way to go. What do you say? Zsolt |
From: Benny M. <ben...@gm...> - 2008-04-11 11:39:01
|
2008/4/11, zsolt foldvari <zso...@gm...>: > > On 4/10/08, Zsolt Foldvari <zso...@gm...> wrote: > > On Thu, 10 Apr 2008 09:33:49 +0200 > > "Benny Malengier" <ben...@gm...> wrote: > > > > > Note that there are some weird things now in editing. Eg, set a piece > > > of text to bold, then click the font icon, and change font, set it > > > too regular. After this, the text is still bold due to the setting of > > > the bold. If bold and italic are in the font chooser, they should > > > change the setting, and perhaps be preselected when font dialog opens > > > (if not two settings in the piece of text)? Only a minor thing. > > > > > > Nice, I never thought about this before. I think I prefer to define > > a custom font selector without the style treeview to make life easier. > > > In r10547 there a workaround. I think this is the easiest way to go. > What do you say? Works for me. It might be nice to have size also not in there, but I suppose it is convenient to have size set together with the font element always. Remark abou the clear icon. It would be better to have it say: 'clear markup' or 'clear markup selection', no? Something else, preformatted checkbox click sets fonts to mono, but if you use FreeSerif or Times New Roman, this has no influence as Mono does not exist there. I still struggle with how to make the preformatted check box easy to understand for the new user. Should we go for preformatted integrated as an icon with corresponding texttag and do away with the box, we could have it relate on GUI with texttag with Pango font description 'Mono', and perhaps a background yellow with stipple to indicate it (not sure what effect that would give, but it would be distinct and not too intrusive). Benny > Zsolt > |
From: zsolt f. <zso...@gm...> - 2008-04-11 13:41:36
|
On 4/11/08, Benny Malengier <ben...@gm...> wrote: > Works for me. It might be nice to have size also not in there, but I suppose > it is convenient to have size set together with the font element always. For that I'll have to separate the font face and font size tags. It's on my todo list. > Remark abou the clear icon. It would be better to have it say: 'clear > markup' or 'clear markup selection', no? Please feel free to change, I don't have a strong opinion here. > Something else, preformatted checkbox click sets fonts to mono, but if you > use FreeSerif or Times New Roman, this has no influence as Mono does not > exist there. Yes, probably we need to clear the font tags also and toolbar should be disbaled as well. Though, the those cleared font tags will be lost forever. See also below. > I still struggle with how to make the preformatted check box easy to > understand for the new user. Should we go for preformatted integrated as an > icon with corresponding texttag and do away with the box, we could have it > relate on GUI with texttag with Pango font description 'Mono', and perhaps a > background yellow with stipple to indicate it (not sure what effect that > would give, but it would be distinct and not too intrusive). I'm still thinking about this too. Perhaps I have a way to integrate it into the tagging system, though not without some complications. Complication is coming from the fact that this way we would have a new concept: conflicting tags (font and preformatted). Also, as you mentioned too, turning preformatted on/off would make all previous tags disappear forever, as I really think we shouldn't get into trying to preserve those. For visualization I thought about dotted underline, as it should be something, what the user can not choose as style. After all, the only advantage of all these I can see is that normal and preformatted could be mixed in one note. I'm not sure if it's worth it. I'm afraid we're already on that slippery slope Brian and others mentioned... Zsolt |
From: Douglas S. B. <db...@cs...> - 2008-04-11 13:56:34
|
[snip] > After all, the only advantage of all these I can see is that normal > and preformatted could be mixed in one note. I'm not sure if it's > worth it. I, for one, would find that useful. I can see adding a small extract from a columnar table, with a bit of italics text explaining it. This would make it more clear that one part is the actual table, and the unpreformatted text is a note that I added about the preformatted. > I'm afraid we're already on that slippery slope Brian and others > mentioned... I can't think of too many other things that I'd like to see. So, this might be a good spot on the slope to stop. > Zsolt |
From: Benny M. <ben...@gm...> - 2008-04-11 14:17:55
|
2008/4/11, zsolt foldvari <zso...@gm...>: > > [snip] > > Something else, preformatted checkbox click sets fonts to mono, but if > you > > use FreeSerif or Times New Roman, this has no influence as Mono does not > > exist there. > > > Yes, probably we need to clear the font tags also and toolbar should > be disbaled as well. Though, the those cleared font tags will be lost > forever. See also below. > > > > I still struggle with how to make the preformatted check box easy to > > understand for the new user. Should we go for preformatted integrated as > an > > icon with corresponding texttag and do away with the box, we could have > it > > relate on GUI with texttag with Pango font description 'Mono', and > perhaps a > > background yellow with stipple to indicate it (not sure what effect that > > would give, but it would be distinct and not too intrusive). > > > I'm still thinking about this too. Perhaps I have a way to integrate > it into the tagging system, though not without some complications. > Complication is coming from the fact that this way we would have a new > concept: conflicting tags (font and preformatted). > Also, as you mentioned too, turning preformatted on/off would make all > previous tags disappear forever, as I really think we shouldn't get > into trying to preserve those. > For visualization I thought about dotted underline, as it should be > something, what the user can not choose as style. > > After all, the only advantage of all these I can see is that normal > and preformatted could be mixed in one note. I'm not sure if it's > worth it. > I'm afraid we're already on that slippery slope Brian and others > mentioned... Ok, let's think it over again. First, the preformatted option is causing problems already now, so we have to handle it one way or the other. I agree with Doug that the slippery slope is more in things like bulleted lists, numbered lists, interline spacing, ... . The styled notes is to make reading better by being able to add some bold, to add headers, and to use the font that pleases ones eyes and to have spell checking. Preformatted is a legacy we have to accomodate some way. The main problem appears to be that putting preformatted together with normal notes is that we cannot indicate it visually easily. For the reports, it sufficies to know where preformatted begins and where it ends, so there this does not apply. Therefore, the following idea: have preformatted be a toggle button like bold, but which applies to an entire paragraph or line (whatever is easiest). In preformatted mode, the font selection in toolbar would be disabled, so no font changes. It would then work as follows: 1/user types text, hits enter, and wants to start a preformatted piece of text 2/clicks on the preformatted button, which is now pressed in, font is disabled and changes to default mono. He starts typing. The pressed preformatted icon button in the toolbar and the monospace font are the indication he is in preformatted mode. 3/clicking the preformatted button on newline would go back in normal mode 4/clicking preformatted on a line with text, or on a selection which is part of text, would remove all font tags in that piece of text from newline before it, no next newline, so would make the entire line/paragraph preformatted. Is that simpler? Just an idea to get out of the problems of this mixing. The only problem I see here is that size cannot be governed if font is disabled, but that is not a big problem, and as you said, changing size separately is on your todo. Obviously, some complication in the code is still needed, but it would mainly be in the code on clicking the icon button, and in the code of cursor moment to update the toolbar. As preformatted is for an entire line/paragraph, an indication in the margin could be given if toolbar indication is too unclear, so reading the text is not hindered by underlines and such. Reports would then be able to know preformatted tag is for an entire line, and handle it as appropriate for their backend. Benny |
From: Brian M. <br...@gr...> - 2008-04-11 14:26:52
|
> > I still struggle with how to make the preformatted > check box easy to > > understand for the new user. Should we go for > preformatted integrated as an > > icon with corresponding texttag and do away with > the box, we could have it > > relate on GUI with texttag with Pango font > description 'Mono', and perhaps a > > background yellow with stipple to indicate it (not > sure what effect that > > would give, but it would be distinct and not too > intrusive). > > I'm still thinking about this too. Perhaps I have a > way to integrate > it into the tagging system, though not without some > complications. > Complication is coming from the fact that this way > we would have a new > concept: conflicting tags (font and preformatted). > Also, as you mentioned too, turning preformatted > on/off would make all > previous tags disappear forever, as I really think > we shouldn't get > into trying to preserve those. > For visualization I thought about dotted underline, > as it should be > something, what the user can not choose as style. > > After all, the only advantage of all these I can see > is that normal > and preformatted could be mixed in one note. I'm not > sure if it's > worth it. > I'm afraid we're already on that slippery slope > Brian and others mentioned... Here is an idea worth considering: 1) Remove the Preformatted option. 2) Add a "word wrap" option. 3) Only provide three font face options: "Mono", "Sans", "Times". Each platform would have to translate each font face option to an actual font face. On my computer, "Mono" would translate to "Courier", "Sans" to "Arial" and "Times" to "Times New Roman". I think #3 has multiple benefits: * It makes it more obvious to the user how to select "fixed-width" fonts (possibly more obvious than "preformatted"). * We don't have to attempt to reconcile obscure font face types between multiple platforms (how many people out there have the "Berlin Sans FB Demi" font? I do). * It provides support for mixed "fixed width" and normal fonts in notes. * I makes the slope less slippery. Thoughts? ~Brian |
From: Benny M. <ben...@gm...> - 2008-04-11 15:48:52
|
2008/4/11, Brian Matherly <br...@gr...>: > > > > I still struggle with how to make the preformatted > > check box easy to > > > understand for the new user. Should we go for > > preformatted integrated as an > > > icon with corresponding texttag and do away with > > the box, we could have it > > > relate on GUI with texttag with Pango font > > description 'Mono', and perhaps a > > > background yellow with stipple to indicate it (not > > sure what effect that > > > would give, but it would be distinct and not too > > intrusive). > > > > I'm still thinking about this too. Perhaps I have a > > way to integrate > > it into the tagging system, though not without some > > complications. > > Complication is coming from the fact that this way > > we would have a new > > concept: conflicting tags (font and preformatted). > > Also, as you mentioned too, turning preformatted > > on/off would make all > > previous tags disappear forever, as I really think > > we shouldn't get > > into trying to preserve those. > > For visualization I thought about dotted underline, > > as it should be > > something, what the user can not choose as style. > > > > After all, the only advantage of all these I can see > > is that normal > > and preformatted could be mixed in one note. I'm not > > sure if it's > > worth it. > > I'm afraid we're already on that slippery slope > > Brian and others mentioned... > > > Here is an idea worth considering: > > 1) Remove the Preformatted option. > > 2) Add a "word wrap" option. > > 3) Only provide three font face options: "Mono", > "Sans", "Times". Each platform would have to translate > each font face option to an actual font face. On my > computer, "Mono" would translate to "Courier", "Sans" > to "Arial" and "Times" to "Times New Roman". > > I think #3 has multiple benefits: > * It makes it more obvious to the user how to select > "fixed-width" fonts (possibly more obvious than > "preformatted"). > > * We don't have to attempt to reconcile obscure font > face types between multiple platforms (how many people > out there have the "Berlin Sans FB Demi" font? I do). > > * It provides support for mixed "fixed width" and > normal fonts in notes. > > * I makes the slope less slippery. > > Thoughts? The problem is that for users the word wrap (make edit window larger gives the same) or the fixed font is not what is really important, the fact that whitespace is kept verbatim in web output and other reports, is what they are after. Benny |
From: Jason S. <jsi...@gm...> - 2008-04-12 12:34:19
|
On Fri, 2008-04-11 at 17:42 +0200, Benny Malengier wrote: > 1) Remove the Preformatted option. > > 2) Add a "word wrap" option. > > 3) Only provide three font face options: "Mono", > "Sans", "Times". Each platform would have to translate > each font face option to an actual font face. On my > computer, "Mono" would translate to "Courier", "Sans" > to "Arial" and "Times" to "Times New Roman". > > I think #3 has multiple benefits: > * It makes it more obvious to the user how to select > "fixed-width" fonts (possibly more obvious than > "preformatted"). > > * We don't have to attempt to reconcile obscure font > face types between multiple platforms (how many people > out there have the "Berlin Sans FB Demi" font? I do). > > * It provides support for mixed "fixed width" and > normal fonts in notes. > > * I makes the slope less slippery. > > Thoughts? > > The problem is that for users the word wrap (make edit window larger > gives the same) or the fixed font is not what is really important, the > fact that whitespace is kept verbatim in web output and other reports, > is what they are after. Agreed. There are two important aspects that define preformatted text: monospace font AND preservation of whitespace. 'Word wrap' to me just means how text is displayed in a window. If it has anything to do with the actual style or format of text, in the layout and design world we use 'word wrap' to refer to text that flows around an object (like an image amidst a body of text or if a text box conforms to a contour rather than the usual rectangle. I wouldn't recommend using that term for preformatted/not preformatted. If you are not familiar with HTML, HTML will not recognize more than one single 'space' at a time. If you put three spaces between a word in your HTML document, the web browser will render only one space. This is what is meant by the 'preservation of whitespace'. HTML ignores whitespace. Preformatted recognizes all three spaces. (Just so everyone knows that. I'm not insinuating that anyone in this conversation doesn't :D) I think #3 is spot on as far as not referring to specific fonts. Personally, I'm impressed with the idea of separating presentation from content by way of referencing character count. That's great. Knowing that that's the direction you all are going, what's left to discuss? There are three options: 1 Preformatted Text 2 Simple Text 3 Styled Text Perhaps you are all still resolving how far 'Styled' goes? And, just for the record, the note content is still going to be unchanged regardless of the 'note type', right? I think I heard at one time that selecting 'Preformatted' would add a <pre> tag and the beginning and a </pre> tag at the end of the note body. I hope that's not being considered. -Jason |
From: Brian M. <br...@gr...> - 2008-04-12 13:20:59
|
> If you are not familiar with HTML, HTML will not > recognize more than one > single 'space' at a time. If you put three spaces > between a word in your > HTML document, the web browser will render only one > space. This is what > is meant by the 'preservation of whitespace'. HTML > ignores whitespace. > Preformatted recognizes all three spaces. (Just so > everyone knows that. > I'm not insinuating that anyone in this conversation > doesn't :D) I think that regardless of whether people are familiar with HTML or not, most users are going to expect ALL reports to preserve ALL whitespace ALL the time. This goes for preformatted as well as styled notes. If they pressed the space bar 3 times, they must have had a reason. Perhaps the web reports should replace all occurrences of "space" with   or apply the equivalent style properties. ~Brian |
From: Jason S. <jsi...@gm...> - 2008-04-12 15:38:59
|
On Sat, 2008-04-12 at 06:20 -0700, Brian Matherly wrote: > I think that regardless of whether people are familiar > with HTML or not, most users are going to expect ALL > reports to preserve ALL whitespace ALL the time. This > goes for preformatted as well as styled notes. If they > pressed the space bar 3 times, they must have had a > reason. > > Perhaps the web reports should replace all occurrences > of "space" with   or apply the equivalent style > properties. Well, I hesitate to do that unless it's preformatted. To me, that's dumbing down the program and it won't help users learn the difference (plus the potential of pissing off advanced users). If whitespace is preserved on every note, why are we even bothering with this discussion? We might as well just style the Note section with whitespace:pre; and forget about it. Okay, I don't mean that. I think we will help people learn (since they probably won't be interested enough to read about it, and let's face it, that's how we learned the difference) if we deliver them consistent output/feedback. I think the approach of 'preserving whitespace everywhere' because of an assumption about the knowledge of our users is what brought us to the situation we're in (regarding the Notes section). -Jason P.S. Also, replacing all spaces in notes with non-breaking spaces would make the source code difficult to read. A better idea, if you decide to go this way, would be to do a search/replace on double spaces, representing them with . Then the non-breaking spaces would only show up where a user added more than one space. |
From: James G. S. (jim) <jg...@sa...> - 2008-04-12 16:37:26
|
Jason Simanek wrote: > On Sat, 2008-04-12 at 06:20 -0700, Brian Matherly wrote: >>.. I think that regardless of whether people are familiar >> with HTML or not, most users are going to expect ALL >> reports to preserve ALL whitespace ALL the time. This >> goes for preformatted as well as styled notes. If they >> pressed the space bar 3 times, they must have had a >> reason. >> >> Perhaps the web reports should replace all occurrences >> of "space" with   or apply the equivalent style >> properties. Just a footnote here: web publishing is not the same as traditional print (newspaper, magazines, advertising, etc). Attempts to control things as the spaces between words, etc are really a perversion of the concept. Web pages as _supposed_ to be flexible with respect to the viewing geometry, and viewer's preferences. A lot of designers coming from the traditional publishing world still do not realize that. NB: I am not referring to anyone here! In general, if you want/need to control such detail, then you probably would be better off with a different publishing method. My point: Spending a lot of time trying to make web pages look like (eg) pdf is misdirected effort. Regards, ..jim |
From: Benny M. <ben...@gm...> - 2008-04-12 17:07:20
|
2008/4/12, James G. Sack (jim) <jg...@sa...>: > > Jason Simanek wrote: > > On Sat, 2008-04-12 at 06:20 -0700, Brian Matherly wrote: > >>.. I think that regardless of whether people are familiar > >> with HTML or not, most users are going to expect ALL > >> reports to preserve ALL whitespace ALL the time. This > >> goes for preformatted as well as styled notes. If they > >> pressed the space bar 3 times, they must have had a > >> reason. > >> > >> Perhaps the web reports should replace all occurrences > >> of "space" with   or apply the equivalent style > >> properties. > > > Just a footnote here: web publishing is not the same as traditional > print (newspaper, magazines, advertising, etc). Attempts to control > things as the spaces between words, etc are really a perversion of the > concept. Web pages as _supposed_ to be flexible with respect to the > viewing geometry, and viewer's preferences. A lot of designers coming > from the traditional publishing world still do not realize that. NB: I > am not referring to anyone here! > > In general, if you want/need to control such detail, then you probably > would be better off with a different publishing method. > > My point: Spending a lot of time trying to make web pages look like (eg) > pdf is misdirected effort. which makes the circle round as that is the reason preformatted is offered. For those occasions you really do want to keep formatting (eg a python source file ;-) Used to much, and things like html or latex that do format for you look ugly. Benny |
From: Benny M. <ben...@gm...> - 2008-04-12 12:03:29
|
2008/4/12, Jason Simanek <jsi...@gm...>: > > > On Fri, 2008-04-11 at 17:42 +0200, Benny Malengier wrote: > > > 1) Remove the Preformatted option. > > > > 2) Add a "word wrap" option. > > > > 3) Only provide three font face options: "Mono", > > "Sans", "Times". Each platform would have to translate > > each font face option to an actual font face. On my > > computer, "Mono" would translate to "Courier", "Sans" > > to "Arial" and "Times" to "Times New Roman". > > > > I think #3 has multiple benefits: > > * It makes it more obvious to the user how to select > > "fixed-width" fonts (possibly more obvious than > > "preformatted"). > > > > * We don't have to attempt to reconcile obscure font > > face types between multiple platforms (how many people > > out there have the "Berlin Sans FB Demi" font? I do). > > > > * It provides support for mixed "fixed width" and > > normal fonts in notes. > > > > * I makes the slope less slippery. > > > > Thoughts? > > > > The problem is that for users the word wrap (make edit window larger > > gives the same) or the fixed font is not what is really important, the > > fact that whitespace is kept verbatim in web output and other reports, > > is what they are after. > > [snip] > > I think #3 is spot on as far as not referring to specific fonts. Problem with #3 would be internationalization. I think for western languages not many people care about times new roman or arial, but I have the impression arabic and other exotic languages do have some preferences. Personally, I'm impressed with the idea of separating presentation from > content by way of referencing character count. That's great. Knowing > that that's the direction you all are going, what's left to discuss? > There are three options: > > 1 > Preformatted Text > > 2 > Simple Text > > 3 > Styled Text > > > Perhaps you are all still resolving how far 'Styled' goes? > > And, just for the record, the note content is still going to be > unchanged regardless of the 'note type', right? I think I heard at one > time that selecting 'Preformatted' would add a <pre> tag and the > beginning and a </pre> tag at the end of the note body. I hope that's > not being considered. That was a user (David) , adding that to his text, hoping everything would show nicely in his web report. Users are allowed to do that, but we obviously do not support it, as it makes the other reports useless (he actually also adds <ul> and such to his notes I think). About the options, the discussion is about the fact if we internally cannot represent 1 ( Preformatted Text) with the same mechanism we doe 3, and in the same time simplify the user interface by not offering a preformatted check box anymore, but an icon button on the toolbar instead. Benny |
From: Jason S. <jsi...@gm...> - 2008-04-12 12:29:11
|
On Sat, 2008-04-12 at 14:03 +0200, Benny Malengier wrote: > That was a user (David) , adding that to his text, hoping everything > would show nicely in his web report. Users are allowed to do that, but > we obviously do not support it, as it makes the other reports useless > (he actually also adds <ul> and such to his notes I think). > About the options, the discussion is about the fact if we internally > cannot represent 1 ( Preformatted Text) with the same mechanism we doe > 3, and in the same time simplify the user interface by not offering a > preformatted check box anymore, but an icon button on the toolbar > instead. Thanks for clearing that up for me. I'm in agreement with the approach you (Benny) outlined: two modes (Plain, Styled) with Preformatted being an option within Styled for one continuous paragraph of text. I don't see a great deal of benefit in mixing Preformatted with other 'styles' of text in one note. Especially if it is technically difficult to accomplish. And mixing them in one paragraph is even less useful. What you described seems to mirror what the users are asking for and is a good compromise. -Jason |