Linus, Robert described perfectly whats happening, the problem is only the dive notes generated by the planner ( it has an HTML table) and saving that as simples text breaks the format tina completely.
You tell me what to do and I'll do, but for now I dont know what should I do to keep the dive planner and the notes correct, if not saving them in HTML. Em 20/07/2014 05:10, "Robert Helling" <[email protected]> escreveu: > > On 20 Jul 2014, at 08:49, Linus Torvalds <[email protected]> > wrote: > > Good morning! > > > I have no idea where this insanity started, but this is seriously > > useless and complete crap. > > I think I can help with that question. When I redid the “planned dive to > notes” to make it include a runtime table I thought about the “table” part > of that. In my first version, I had an ascii table which of course looked > “complete crap” when presented in a proportional font. Then I tried to > figure out how to enforce a fixed width font and realised that this (in > Qt’s way) would be done by applying a style sheet which would make the > notes effectively html. But with that, I thought, we can actually use an > html table for the table, which it is now. Then somebody took off from > there and added red color and boldface to the notes generated by the > planner. So that the notes are now html. > > Then somebody complained that after saving and reloading their notes > displayed html source. And iirc that prompted Tomaz to write the code that > you are worried about right now. > > I think, what is needed here is an executive decision on what the notes > are: > > 1) plain text (i.e. no color, boldface and table generated by the > planner). I must say even though I see the purity argument for that I don’t > like this option very much. And we somehow gave up on this when we gave up > 7bit ASCII in favour of unicode. > > 2) html (as partly generated by Qt) which is the current situation which > has the main disadvantage that it looks “complete crap” as soon as you open > the .xml or the git file in an editor but is opaque to the user. > > 3) have some mild form of mark up/rich text (for table, boldface, color) > but only store that part that is absolutely necessary. We could implement > that with some intermediate representation (we could store a mildly marked > up version of the notes and only display the proper html, so have a > different internal representation than what we display, as we do with units > etc) or we could get rid of all unnecessary html tags when storing > (possibly with xslt). This option of course would need more coding. A mild > version would be to memorise if notes are pure ascii (as entered by the > user) or proper html (as generated by the planner) and store and display > accordingly. > > Unfortunately, we can not go with 2) for the moment and hope to move to 1) > or 3) later as then all users files would be “poisoned” by the > html-garbledigog that we have now. > > Best > Robert > > _______________________________________________ > subsurface mailing list > [email protected] > http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface > >
_______________________________________________ subsurface mailing list [email protected] http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
