From: Benny M. <ben...@gm...> - 2008-04-09 07:43:00
|
2008/4/9, Stephen George <ste...@op...>: > > Hi James, > > Good roundup of the discussion. > I haven't been on the list very long, has the thought of reStructured > text been considered for the Notes format? > Can give some structure to the html and other output formats but still > looks good in plain text > i.e. > support for tables > http://docutils.sourceforge.net/docs/user/rst/quickref.html#tables > > Can output html fragments as noted on this page > http://wiki.python.org/moin/ReStructuredText Somebody mentioned this before. It is nice for geeks, but a typical genealogical researcher will have no use for it. Effectively, it is an interpreted language, which needs compiling, like latex. Our notes are more wysiwyg, which is more fitting for regular users. In my opinion at least.. Hell, I already know latex, so why not use that ;-) Well, to go deeper, a new structure would be needed, with two editing modes, one structured text editing, one normal editing, with the ability to switch between the two. A lot of work, not easy, more complicated testing, and for storage, only one thing can be used. The new tags system Zsolt is making is better for our goal, as for export, the plain text does not need parsing to store eg in GEDCOM, or to load in other applications. This is a very important benefit in promoting our xml format. Benny Steve > > > James G. Sack (jim) wrote: > > 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 > > > > > > > ------------------------------------------------------------------------- > 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 > |