From: Zsolt F. <zso...@gm...> - 2007-07-16 18:46:26
|
Once I have already requested opinions about how we should tag the formatted notes. Thanks to all who responded. Now, this is the proposal, and the currently working implementation in the latest SVN release: Bold: <b> </b> Italic: <i> </i> Underline: <u> </u> Font: <font face="font_name"> </font> Font size: <font size="size"> </font> Font color: <font color="color"> </font> Font highlight: <font highlight="color"> </font> Is there any better idea? Shall we include some other formatting, or remove any of these before 2.3/3.0 is released? Does the current implementation work? ;-) Zsolt |
From: <ste...@gm...> - 2007-07-16 20:11:20
|
Do we want to throw in <br> and/or <p>? I guess the advantage of all these tags is they'll translate easily when NarrativeWeb needs to display notes. Stephane Charette On 7/16/07, Zsolt Foldvari <zso...@gm...> wrote: > Once I have already requested opinions about how we should tag the > formatted notes. Thanks to all who responded. > > Now, this is the proposal, and the currently working implementation in > the latest SVN release: > > Bold: <b> </b> > Italic: <i> </i> > Underline: <u> </u> > Font: <font face="font_name"> </font> > Font size: <font size="size"> </font> > Font color: <font color="color"> </font> > Font highlight: <font highlight="color"> </font> > > Is there any better idea? > Shall we include some other formatting, or remove any of these before > 2.3/3.0 is released? > Does the current implementation work? ;-) > > Zsolt > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Don A. <don...@co...> - 2007-07-17 13:02:40
|
The tricky part is getting other formats (not just HTML) to understand the formatting. Part of the problem is that ODT (OpenDocument) requires all formats to be specified up front. So embedded formatting can present a problem. For something like bold, italic and underline, this is easy. These are fixed items. But for change of font face, color and size, which take an argument that is variable, this is not easy to do. By the time we see the change of font, size or color, we have already had to specify our format styles.=20 This would probably require a multi stage pass on the document, which is a fairly big departure from what we currently have. To fully support this may require a revamp of our document generators. I'm not saying this can't be done - just that it might take a while for formats other than HTML to support all the features. Don On Mon, 2007-07-16 at 13:11 -0700, St=C3=A9phane Charette wrote: > Do we want to throw in <br> and/or <p>? >=20 > I guess the advantage of all these tags is they'll translate easily > when NarrativeWeb needs to display notes. >=20 > Stephane Charette >=20 >=20 > On 7/16/07, Zsolt Foldvari <zso...@gm...> wrote: > > Once I have already requested opinions about how we should tag the > > formatted notes. Thanks to all who responded. > > > > Now, this is the proposal, and the currently working implementation in > > the latest SVN release: > > > > Bold: <b> </b> > > Italic: <i> </i> > > Underline: <u> </u> > > Font: <font face=3D"font_name"> </font> > > Font size: <font size=3D"size"> </font> > > Font color: <font color=3D"color"> </font> > > Font highlight: <font highlight=3D"color"> </font> > > > > Is there any better idea? > > Shall we include some other formatting, or remove any of these before > > 2.3/3.0 is released? > > Does the current implementation work? ;-) > > > > Zsolt > > > > -----------------------------------------------------------------------= -- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Gramps-devel mailing list > > Gra...@li... > > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > >=20 > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Duncan L. <dli...@gm...> - 2007-07-21 13:29:56
|
On Tue, 2007-07-17 at 07:02 -0600, Don Allingham wrote: > The tricky part is getting other formats (not just HTML) to understand > the formatting. Part of the problem is that ODT (OpenDocument) requires > all formats to be specified up front. So embedded formatting can present > a problem. For something like bold, italic and underline, this is easy. > These are fixed items. But for change of font face, color and size, > which take an argument that is variable, this is not easy to do. By the > time we see the change of font, size or color, we have already had to > specify our format styles. ... this is what my other email is about. Duncan |
From: Zsolt F. <zso...@gm...> - 2007-07-17 17:50:56
|
At the moment we have Flowed/Formatted notes, which determines how paragraphs are handled. I think introducing <br>, <p> tags would conflict with this current implementation. I'm not sure though. Zsolt On Mon, 16 Jul 2007 13:11:21 -0700 "St=E9phane Charette" <ste...@gm...> wrote: > Do we want to throw in <br> and/or <p>? >=20 > I guess the advantage of all these tags is they'll translate easily > when NarrativeWeb needs to display notes. >=20 > Stephane Charette >=20 >=20 > On 7/16/07, Zsolt Foldvari <zso...@gm...> wrote: > > Once I have already requested opinions about how we should tag the > > formatted notes. Thanks to all who responded. > > > > Now, this is the proposal, and the currently working implementation > > in the latest SVN release: > > > > Bold: <b> </b> > > Italic: <i> </i> > > Underline: <u> </u> > > Font: <font face=3D"font_name"> </font> > > Font size: <font size=3D"size"> </font> > > Font color: <font color=3D"color"> </font> > > Font highlight: <font highlight=3D"color"> </font> > > > > Is there any better idea? > > Shall we include some other formatting, or remove any of these > > before 2.3/3.0 is released? > > Does the current implementation work? ;-) > > > > Zsolt > > > > -----------------------------------------------------------------------= -- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Gramps-devel mailing list > > Gra...@li... > > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: <rom...@ya...> - 2007-07-18 09:07:28
|
Zsolt, > Does the current implementation work? ;-) Gramps: SVN 8733 I get an error when I try to select font name + font color + background color on the same word/note. 166757: ERROR: gramps.py: line 147: Unhandled exception Traceback (most recent call last): File "src/Editors/_EditNote.py", line 395, in save self.update_note() File "src/Editors/_EditNote.py", line 381, in update_note text = buffer.get_text(start, stop) File "src/MarkupText.py", line 956, in get_text self.writer.generate(txt, xml_elements) File "src/MarkupText.py", line 314, in generate events = self._elements_to_events(elements) File "src/MarkupText.py", line 197, in _elements_to_events eventdict[index].insert(0, (name, tmp_attrs, KeyError: 'font' Zsolt Foldvari a écrit : > Once I have already requested opinions about how we should tag the > formatted notes. Thanks to all who responded. > > Now, this is the proposal, and the currently working implementation in > the latest SVN release: > > Bold: <b> </b> > Italic: <i> </i> > Underline: <u> </u> > Font: <font face="font_name"> </font> > Font size: <font size="size"> </font> > Font color: <font color="color"> </font> > Font highlight: <font highlight="color"> </font> > > Is there any better idea? > Shall we include some other formatting, or remove any of these before > 2.3/3.0 is released? > Does the current implementation work? ;-) > > Zsolt |
From: zsolt f. <zso...@gm...> - 2007-07-18 21:41:27
|
Should be fixed now (SVN 8740) Zsolt On 7/18/07, J=E9r=F4me <rom...@ya...> wrote: > Zsolt, > > > > Does the current implementation work? ;-) > > Gramps: SVN 8733 > > I get an error when I try to select font name + font color + background > color on the same word/note. > > 166757: ERROR: gramps.py: line 147: Unhandled exception > Traceback (most recent call last): > File "src/Editors/_EditNote.py", line 395, in save > self.update_note() > File "src/Editors/_EditNote.py", line 381, in update_note > text =3D buffer.get_text(start, stop) > File "src/MarkupText.py", line 956, in get_text > self.writer.generate(txt, xml_elements) > File "src/MarkupText.py", line 314, in generate > events =3D self._elements_to_events(elements) > File "src/MarkupText.py", line 197, in _elements_to_events > eventdict[index].insert(0, (name, tmp_attrs, > KeyError: 'font' > > > > Zsolt Foldvari a =E9crit : > > Once I have already requested opinions about how we should tag the > > formatted notes. Thanks to all who responded. > > > > Now, this is the proposal, and the currently working implementation in > > the latest SVN release: > > > > Bold: <b> </b> > > Italic: <i> </i> > > Underline: <u> </u> > > Font: <font face=3D"font_name"> </font> > > Font size: <font size=3D"size"> </font> > > Font color: <font color=3D"color"> </font> > > Font highlight: <font highlight=3D"color"> </font> > > > > Is there any better idea? > > Shall we include some other formatting, or remove any of these before > > 2.3/3.0 is released? > > Does the current implementation work? ;-) > > > > Zsolt > |
From: Duncan L. <dli...@gm...> - 2007-07-18 13:05:33
|
I'm coming into this discussion pretty late, and I'm not a dev, but anyway... Now on my third version of this email... I'm a bit concerned about feature creep with the features in the notes tab and that if it gets too complex it will just create problems with the reports. For instance if it tries to be too clever could that interfere with how easily I can modify the ODF report output? If the system of style tags isn't consistent won't that be a pain? If I'm plain wrong just tell me, I don't need a big explanation. In general though I don't like the idea of <font> tags as in the current implementation. I think that 'styles' offer much better control and (ease of) extensibility. On the current implementation: X Bold: <b></b> X I think the XHTML tag 'Strong' is better than 'Bold', describes function not appearance. Italic: <i></i> Underline: <u></u> I think all the <font> tags should be replaced by generic XHTML style tags. For example the defaults could be: Text style 'Default': <div style="default"></div> Text style 'Plain': <div style="plain"></div> Text style 'Fancy': <div style="fancy"></div> Then a simple style editor with some spin menus would allow us to select a subset of the CSS attributes for the text. The available attributes might include Font, Size, Color, Style and Decoration. As an example: .fancy { font-family:bookman,serif; font-size:120%; color:dark-grey; font-style:italic; text-decoration:underline; } (I think this also solves what Don was talking about as a problem in creating ODF compliant files) Regards, Duncan PS. I think if we go in this styles based direction then the styles should be applied and available across the whole of GRAMPS, not just where we are at that moment. |
From: Don A. <don...@co...> - 2007-07-18 16:08:01
|
Please keep in mind that these tags are *not* user visible. The end user will NEVER see them. These are codes which are embedded in the Note database structure. So, if we really wanted to, we can use <fish> to represent bold, <cat> to represent italics, <font> to represent underline, and $montypython^ to represent fonts. The user will only see a word processor-like interface on the Note Editor. Just like in OpenOffice, the user selects the font from a menu, or selects the Bold button. The user will not have access to these codes, and will not be able to enter or modify these codes.=20 These codes exist to: 1) Allow the new Note Editor to store and load enhanced formatting 2) Allow the document output format generation code to understand what the note is trying to represent so that it can do its best job of duplicating what the user entered into the Note Editor. As a writer of a report, this will be invisible to you. Your selected output format will do its best job to represent what is in the note. If it cannot support something, it will remove the formatting codes and display the text as normal text. The issue I was talking about in ODF files is completely unrelated. Each file format has its own way of representing markup. In basic HTML, the styles are marked up inline. In ODF, all styles must be specified upfront, and then selected inline. Each time you use a new font, a new style must be created up front. This will require a two pass solution. Once to figure out what all the specified styles are, the second to generate output. What this really means is that some formats will be easier to adapt to the markup than others (HTML, which allows me to specify the fonts inline, will be simpler than ODF, which does not). Also, some document formats will never be able to handle all the formatting. Text output cannot support any, LaTeX does not give you control over font information.=20 Summary for the user: It make take a couple of releases before all the major output formats will support formatted notes in reports. So, in summary, what Zsolt uses for his tags matters to no one but the Note Editor and document output formats. The users won't see it, the report writers won't see it. Don On Wed, 2007-07-18 at 15:05 +0200, Duncan Lithgow wrote:=20 > I'm coming into this discussion pretty late, and I'm not a dev, but > anyway... Now on my third version of this email... >=20 > I'm a bit concerned about feature creep with the features in the notes > tab and that if it gets too complex it will just create problems with > the reports. For instance if it tries to be too clever could that > interfere with how easily I can modify the ODF report output? If the > system of style tags isn't consistent won't that be a pain? If I'm > plain wrong just tell me, I don't need a big explanation. >=20 > In general though I don't like the idea of <font> tags as in the > current implementation. I think that 'styles' offer much better > control and (ease of) extensibility. >=20 > On the current implementation: >=20 > X Bold: <b></b> X > I think the XHTML tag 'Strong' is better than 'Bold', describes > function not appearance. >=20 > Italic: <i></i> > Underline: <u></u> >=20 > I think all the <font> tags should be replaced by generic XHTML style > tags. For example the defaults could be: > Text style 'Default': <div style=3D"default"></div> > Text style 'Plain': <div style=3D"plain"></div> > Text style 'Fancy': <div style=3D"fancy"></div> >=20 > Then a simple style editor with some spin menus would allow us to > select a subset of the CSS attributes for the text. The available > attributes might include Font, Size, Color, Style and Decoration. As > an example: >=20 > .fancy { font-family:bookman,serif; font-size:120%; color:dark-grey; > font-style:italic; text-decoration:underline; } >=20 > (I think this also solves what Don was talking about as a problem in > creating ODF compliant files) >=20 > Regards, Duncan > PS. I think if we go in this styles based direction then the styles > should be applied and available across the whole of GRAMPS, not just > where we are at that moment. >=20 > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Duncan L. <dli...@gm...> - 2007-07-21 13:28:48
|
On Wed, 2007-07-18 at 10:07 -0600, Don Allingham wrote: > The issue I was talking about in ODF files is completely unrelated. Each > file format has its own way of representing markup. In basic HTML, the > styles are marked up inline. In ODF, all styles must be specified > upfront, and then selected inline. Each time you use a new font, a new > style must be created up front. This will require a two pass solution. > Once to figure out what all the specified styles are, the second to > generate output. But this is exactly what I'm on about. If the internal way of dealing with different formats/styles/fonts is via styles, not inline, but up front as with CSS and XHTML, then we can define our 'styles' up front for the ODF reports - just as stylesheets do for an HTML page. I may be wrong but I imagine that any other way would give code which is not just much harder to maintain but also harder to parse when creating reports. > > So, in summary, what Zsolt uses for his tags matters to no one but the > Note Editor and document output formats. The users won't see it, the > report writers won't see it. But it should be easy to maintain, yes? Though I'm no expert on that, I just want to check that it's kept in mind. Duncan |
From: <bm...@ca...> - 2007-07-25 10:11:01
|
Hi, great work Zsolt! I do have some usability issues however. I see users of GRAMPS 3.0 start using the extended note formatting extensively, eg full transcripts, todo lists, personal histories. All added in GRAMPS directly instead of in an office document that is attached to the person. Which will lead to the following: 1/Undo. When having written a serious text, people do make errors, like deleting a paragraph, wrong paste, clicking the clear text icon, ... Without an Undo, we should not really encourage the users to use GRAMPS note's for serious text input, or people will start loosing data and get very angry. Is undo feasible? 2/intermediate save. If people have written a paragraph of text, they really should be able to do an intermediate save of the note without clicking the OK button and reopening the note. So a save button would be needed. If Undo is a to difficult implementation, offering a save and restore button might be an acceptable alternative: you save before a serious edit, and the restore button retrieves the last saved text for you. 3/collaboration. People need to correspond with family members, researchers. If people start entering a family history in nice formating into a note of GRAMPS, we should allow a possibility to allow to share the formatted note with other people, so a copy/paste option into openoffice, or an export to openoffice format where all formatting is retained. One can hardly expect users to agree with the possibility of making nice texts in gramps without the ability to share them. Of course, we will also receive very soon feature requests of the inverse: people receiving marked up texts/emails, and wanting to copy the markup text into a GRAMPS note retaining markup. Do you guys agree with these observations? Benny Quoting Don Allingham <don...@co...>: > Please keep in mind that these tags are *not* user visible. The end user > will NEVER see them. These are codes which are embedded in the Note > database structure. So, if we really wanted to, we can use <fish> to > represent bold, <cat> to represent italics, <font> to represent > underline, and $montypython^ to represent fonts. > > The user will only see a word processor-like interface on the Note > Editor. Just like in OpenOffice, the user selects the font from a menu, > or selects the Bold button. The user will not have access to these > codes, and will not be able to enter or modify these codes. > > These codes exist to: > > 1) Allow the new Note Editor to store and load enhanced formatting > 2) Allow the document output format generation code to understand what > the note is trying to represent so that it can do its best job of > duplicating what the user entered into the Note Editor. > > As a writer of a report, this will be invisible to you. Your selected > output format will do its best job to represent what is in the note. If > it cannot support something, it will remove the formatting codes and > display the text as normal text. > > The issue I was talking about in ODF files is completely unrelated. Each > file format has its own way of representing markup. In basic HTML, the > styles are marked up inline. In ODF, all styles must be specified > upfront, and then selected inline. Each time you use a new font, a new > style must be created up front. This will require a two pass solution. > Once to figure out what all the specified styles are, the second to > generate output. > > What this really means is that some formats will be easier to adapt to > the markup than others (HTML, which allows me to specify the fonts > inline, will be simpler than ODF, which does not). Also, some document > formats will never be able to handle all the formatting. Text output > cannot support any, LaTeX does not give you control over font > information. > > Summary for the user: It make take a couple of releases before all the > major output formats will support formatted notes in reports. > > So, in summary, what Zsolt uses for his tags matters to no one but the > Note Editor and document output formats. The users won't see it, the > report writers won't see it. > > Don > > On Wed, 2007-07-18 at 15:05 +0200, Duncan Lithgow wrote: >> I'm coming into this discussion pretty late, and I'm not a dev, but >> anyway... Now on my third version of this email... >> >> I'm a bit concerned about feature creep with the features in the notes >> tab and that if it gets too complex it will just create problems with >> the reports. For instance if it tries to be too clever could that >> interfere with how easily I can modify the ODF report output? If the >> system of style tags isn't consistent won't that be a pain? If I'm >> plain wrong just tell me, I don't need a big explanation. >> >> In general though I don't like the idea of <font> tags as in the >> current implementation. I think that 'styles' offer much better >> control and (ease of) extensibility. >> >> On the current implementation: >> >> X Bold: <b></b> X >> I think the XHTML tag 'Strong' is better than 'Bold', describes >> function not appearance. >> >> Italic: <i></i> >> Underline: <u></u> >> >> I think all the <font> tags should be replaced by generic XHTML style >> tags. For example the defaults could be: >> Text style 'Default': <div style="default"></div> >> Text style 'Plain': <div style="plain"></div> >> Text style 'Fancy': <div style="fancy"></div> >> >> Then a simple style editor with some spin menus would allow us to >> select a subset of the CSS attributes for the text. The available >> attributes might include Font, Size, Color, Style and Decoration. As >> an example: >> >> .fancy { font-family:bookman,serif; font-size:120%; color:dark-grey; >> font-style:italic; text-decoration:underline; } >> >> (I think this also solves what Don was talking about as a problem in >> creating ODF compliant files) >> >> Regards, Duncan >> PS. I think if we go in this styles based direction then the styles >> should be applied and available across the whole of GRAMPS, not just >> where we are at that moment. >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Duncan L. <dli...@gm...> - 2007-07-25 10:43:18
|
On Wed, 2007-07-25 at 12:10 +0200, bm...@ca... wrote: > Hi, great work Zsolt! > > I do have some usability issues however. I see users of GRAMPS 3.0 start using > the extended note formatting extensively, eg full transcripts, todo lists, > personal histories. All added in GRAMPS directly instead of in an office > document that is attached to the person. What about a way to export a note which will attach it the object where the note was written? In this way we could add a warning when people have typed a lot into a note, like: "This note tab is not designed for important texts. We recommend you export this text and attach it to this object. Should we do this now?" Yes | No | Ask Later I'm happy about the notes but really see a lot of problems with bloated databases and similar problems. Duncan |
From: Eero T. <ee...@us...> - 2007-07-29 17:08:10
|
Hi, On Wednesday 25 July 2007, bm...@ca... wrote: > I do have some usability issues however. I see users of GRAMPS 3.0 start > using the extended note formatting extensively, eg full transcripts, todo > lists, personal histories. All added in GRAMPS directly instead of in an > office document that is attached to the person. > > Which will lead to the following: > > 1/Undo. When having written a serious text, people do make errors, like > deleting > a paragraph, wrong paste, clicking the clear text icon, ... > Without an Undo, we should not really encourage the users to use GRAMPS > note's for serious text input, or people will start loosing data and get > very angry. Is undo feasible? > > 2/intermediate save. If people have written a paragraph of text, they > really should be able to do an intermediate save of the note without > clicking the OK button and reopening the note. So a save button would be > needed. If Undo is a to difficult implementation, offering a save and > restore button might be an acceptable alternative: you save before a > serious edit, and the restore button retrieves the last saved text for > you. This kind of an advanced editor should probably be a component integrated from somewhere else (scintilla?), Gramps focus is not a word processing... However, embedding desktop environment UI components could make Gramps less portable. People have of course also the option of copy pasting the text between a real text editor and Gramps input field (Iike I do often with Wiki), but an attached separate document could then be better. > 3/collaboration. People need to correspond with family members, > researchers. If people start entering a family history in nice formating > into a note of GRAMPS, > we should allow a possibility to allow to share the formatted note with > other people, so a copy/paste option into openoffice, or an export to > openoffice format where all formatting is retained. One can hardly expect > users to agree with the possibility of making nice texts in gramps > without the ability to share them. Of course, we will also receive very > soon feature requests of the inverse: people receiving marked up > texts/emails, and wanting to copy the markup text into a GRAMPS note > retaining markup. Gtk (2.10) text widgets at least support rich text copy/pasting between processes, however I'm not sure whether this is a standard supported by Qt/KDE programs and/or OpenOffice: http://www.pygtk.org/docs/pygtk/class-gtkclipboard.html#method-gtkclipboard--request-rich-text According to this old mail, they should support at least some kind of rich text copy/paste: http://lists.freedesktop.org/archives/xdg/2003-August/000605.html - Eero |
From: Piotr C. <pio...@gm...> - 2007-07-29 22:54:13
|
On 7/16/07, Zsolt Foldvari <zso...@gm...> wrote: > Once I have already requested opinions about how we should tag the > formatted notes. Thanks to all who responded. > > Now, this is the proposal, and the currently working implementation in > the latest SVN release: > > Bold: <b> </b> > Italic: <i> </i> > Underline: <u> </u> > Font: <font face="font_name"> </font> > Font size: <font size="size"> </font> > Font color: <font color="color"> </font> > Font highlight: <font highlight="color"> </font> > > Is there any better idea? > Shall we include some other formatting, or remove any of these before > 2.3/3.0 is released? > Does the current implementation work? ;-) > > Zsolt I've just checked the new formatted notes. I find it useful enough with its current possibilities. The only disturbing thing is that in contrast to all known to me word processors foramatting buttons are ordered italic-bold-underline instead of bold-italic-underline. I also hope that it will also be possible to copy note references between objects and not only notes from the Notes view as it is now. Piotrek |