Merge branch 'upstream' into debian/sid

1 files changed, 38 insertions, 6 deletions

diff --git a/data/doc/sisu/sisu_markup_samples/sisu_manual/sisu_faq.sst b/data/doc/sisu/sisu_markup_samples/sisu_manual/sisu_faq.sst
index 795367d3..f7fead86 100644
--- a/data/doc/sisu/sisu_markup_samples/sisu_manual/sisu_faq.sst
+++ b/data/doc/sisu/sisu_markup_samples/sisu_manual/sisu_faq.sst
@@ -6,7 +6,7 @@
 
 @creator: Ralph Amissah
 
-@rights: Copyright (C) Ralph Amissah 2007, part of SiSU documentation, License GPL 3
+@rights: Copyright (C) Ralph Amissah 2008, part of SiSU documentation, License GPL 3
 
 @type: information
 
@@ -18,9 +18,9 @@
 
 @date.issued: 2006-09-06
 
-@date.modified: 2007-09-16
+@date.modified: 2008-03-12
 
-@date: 2007-09-16
+@date: 2008-03-12
 
 @level: new=C; break=1; num_top=1
 
@@ -132,6 +132,16 @@ Where there are large document sets, it provides consistency in appearance in ea
 
 The excuse for going this way is, it is a waste of time to think much about appearance when working on substantive content, it is the substantive content that is relevant, not the way it looks beyond the basic informational tags - and yet you want to be able to take advantage of as many useful different ways of representing documents as are available, and for various types of output to to be/look as good as it can for each medium/format in which it is presented, (with different mediums having different focuses) and SiSU tries to achieve this from minimal markup.
 
+2~ Can the SiSU markup be used to prepare for a LaTex automatic building of an index to the work?
+
+Has not been, is of interest though the question on introducing such possibilities is how to keep them as unobtrusive as possible, and as generically relevant as possible to other output formats (which is why the focus on object numbers). Unobtrusive refers both to the markup (where there is no big problem with introducing optional extras); and, more challengingly how to minimise impact on competing ideas/interests, such allowing the addition of semantic tags which could be tied to objects, mapped against the objects that contain them, (permitting mapping and mining of content in various ways that would be largely agnostic of output format - object numbering being an attempt to move beyond output format based content locators (such as page numbers). The desire being to (be a meta markup and) maintain agnosticism as to what is being generated and in development to favor solutions of that nature. Keep bridging LaTeX, XML, SQL ... make use of objects and serialisation for mapping whether against content or meta-content (such as semantic [or additional structural] markers).
+
+2~ Can the conversion from SiSU to LaTeX be modified if we have special needs for the LaTeX, or do we need to modify the LaTeX manually?
+
+Should be possible to modify code, it is GPLv3, should be possible either to modify existing modules or write an independent module for generating bespoke latex. Generic improvements are welcome for inclusion/incorporation in the existing code base.
+
+If there are tools to generate mathematical/scientific formula from latex to images (jpg, png), the latex parser could conceivably be used to make these available to other output formats.
+
 2~ How do I create GIN or GiST index in Postgresql for use in SiSU
 
 This at present needs to be done "manually" and it is probably necessary to alter the sample search form. The following is a helpful response from one of the contributors of GiN to Postgresql Oleg Bartunov 2006-12-06:
@@ -175,11 +185,33 @@ Now you can search:
 
 select lid, metadata_tid, rank_cd(fts, q,2)as rank from document, plainto_tsquery('markup syntax') q where q @@ fts order by rank desc limit 10;
 
+2~ Are there some examples of using Ferret Search with a SiSU repository?
+
+Heard good things about Ferret, but have not used it. The output directory structure and content produced by SiSU is very uniform. Have looked at a couple of other engines (hyperestraier, lucene). There it was enough to identify the files that needed to be indexed and pass them to the search indexing tool. Some Unix rune doing the job, such as:
+
+code{
+
+find /home/ralph/sisu_www -type f | \
+egrep '/sisu_www/(sisu|document_archive)/.+?.html$' | \
+egrep -v '(doc|concordance).html$' | \
+estcmd gather -sd casket -
+
+}code
+
+you would have to experiment with what gives the desired result, the file doc.html is the complete text in html (there are additional smaller html segments), and plain.txt the document as a text file. It may be possible to index the text file and return the html document.
+
+
+2~ Have you had any reports of building SiSU from tar on Mac OS 10.4?
+
+None. In the early days of its release a Mac friend built and run the ruby code part that did not rely on system calls to bits like the latex engine. That is already some years back. He was not into writing or document markup, and did it as a favour at the time. I have not followed up that thread of development.
+
+It should however be possible, much of the output relies on plain ruby, and the system commands to latex etc. could be made appropriate for the underlying OS.
+
 2~ Where is version 1.0?
 
-SiSU works pretty well as it is supposed to.
-Version 1.0 will have the current markup, and directory structure.
-At this point it is largely a matter of choice as to when the name change is made.
+Most of SiSU is mature and stable.
+Version 1.0 will be based on the current markup, (more likely with optional additions rather than significant changes) and directory structure.
+At this point (semantic tagging apart) it is largely a matter of choice as to when the version change is made.
 
 The feature set for html,~{ html w3c compliance has been largely met. }~ LaTeX/pdf and opendocument is in place.
 XML, and plaintext are in order.