2008/3/1, Brian Matherly <brian@...>:
> > As notes are new in 3.0, we should have it right
> > from the beginning.
> > There appears to be a problem though: see
> > http://bugs.gramps-project.org/view.php?id=1863 and
> > related
> > I won't have time in the near future to look at
> > this, and the person who
> > wrote the code also is not around, so somebody
> > should step up to
> > investigate.
> > It appears the <gramps>... </gramps> tag is added
> > sometimes needlessly. Some
> > logical way needs to be found to handle this. I
> > don't understand why not all
> > notes can have this root tag. Differences could be
> > given in attributes, and
> > doing a get on a text could do eg conversion based
> > on this attribute
> > (preformatted, markup or not, ...).
> > We have to allow also for users typing < and > in
> > the note without messing
> > that up in eg preview and note code, we need to
> > allow for markup or not
> > markup, ...
> Just for my own edification, let me make sure I
> understand the use cases surrounding the current
> implementation. I remember 4 possible scenarios:
For me only 1, 2 and 3 are are use cases. The html is just the same as a
plain old note. Obviously, a user pasting html/php code will have many < and
> and other ascii symbols, but for GRAMPS that should not matter, it is a
plain old note.
So, we are left with:
1) Plain old notes
> In this situation, the user just wants some text to be
> entered for later retrieval and display in reports. No
> special formatting is required. I believe this is by
> FAR the most common use case and the most important.
Indeed, problem is that now it appears they sometimes have the <gramps> thag
and sometimes not, and < and > fields in a plain note get stripped in
preview and other places, which should not be the case.
It might be possible to always store these notes in the same way as pseudo
word processor notes? Why should we check if there is markup or not, and
depending on that decide what to do?
2) Fixed-width ASCII
> In this situation, the user has arranged the text
> using spaces in such a way that when displayed with a
> fixed-width font, the text is aligned in to rows and
> columns, or has some other temporal relationship that
> conveys information in addition to the text itself.
> There are lots of plain text documents on the internet
> that have data arranged into a table. When viewed with
> a text editor, the table is visible. When viewed with
> a word processor (without fixed-width fonts), the
> columns do not align. We added the "preformatted"
> checkbox on the note editor to allow the user to
> signal that the text should be displayed with a
> fixed-width font. I believe this is the second most
> important use case.
Yes, I have no idea how we store this now, did not investigate
3) Pseudo-word processor text
> Some users might want to emphasize parts of the text
> by changing the font properties. These properties
> include font face, font color, and background color.
> Pango markup was chosen as the way to signal these
> properties because GTK will generate it for us
> automatically. The <gramps> tag was added as a way to
> indicate that the pango markup is present in the note.
> I believe this use case is less important than #2 for
> two reasons: a) For advanced formatting, the user has
> the option to use a word processor and attach the
> resulting document as a media file and b) Gramps isn't
> really that great as a wordprocessor (which is why I
> call it pseudo-word processor).
Yes, but unfortunately I think many people will use this a lot in the near
future. I can image headers, bold and underline to be great favorites.
4) HTML storage for narrative web report
> Some users have a need to store HTML markup in a
> location to be inserted into the HTML generated by the
> narrative web report. Originally, that markup was
> added to a media object in the database. When
> generating a narrative web report, the user would
> select a media object to be inserted in header (for
> example). Since notes have been added, that
> responsibility was given to the notes. Now, a user can
> enter a note with raw HTML markup, and select that
> note to be inserted in the header of a narrative web
> report. I think this use case is the least important
> of all. For one thing, the HTML markup is probably not
> genealogical information. Examples of when this would
> be used include publisher contact information and
> legal notices.
I don't think this is a use case as said. A user enters text with strange
symbols, Gramps shouldn't care if it is html.
Where html comes in is in output. For output we have to choose how to work.
Therefore we need some functions
--> get : just return the text. This means that if gramps replaced < with an
internal code, we should change it back to what user actually entered.
--> get_no_markup: remove all the tags added by GRAMPS. This is needed for
export to eg GEDCOM, and for reports. This is where things go wrong now,
gramps removes too much apparently.
--> get_style_report: this would be get the note, but replace the tags of
GRAMPS so that it appears the same in the report as in GRAMPS. This function
does not exist yet, I don't think we should add it, but we can expect users
requesting it once 3.0 is out. In this method one could have a get_as_html
which replaces eg bold by a bold as coded in html.
Have I captured things properly?
> If so, then we clearly have conflicting use cases
> between #2, #3 and #4.
If we have a flag for 2, I don't think there is a conflict. The flag is set,
and we can take action based on that. It does complicate things a lot.