Re: [help-texinfo] IXIN 1.7 available
On Sat, Jan 19, 2013 at 10:20:30PM +0100, Patrice Dumas wrote: I'll now take a stab at a first IXIN output implementation. I'll do it with some abstraction, such that other output format than lisp-like may be output with the same information structure, for instance XML. I have done an implementation. It is not complete as I haven't implemented the element that required answers to my questions. Also * I added some byte counts (all the indices have an associated byte count) * I changed the order to put expandable strings more consistently at the end, to allow to use attributes for strings in XML. * no associated node is always -1 * for index entry fonts, instead of - in front, it is r or code as the third argument To do the .ixin file, call texi2any like texi2any -c TEXINFO_OUTPUT_FORMAT=ixinsxml myfile.texi -- Pat
Re: [help-texinfo] IXIN 1.7 available
On Fri, Jan 18, 2013 at 02:40:42AM +0100, Patrice Dumas wrote: The node label is missing in the 'node index'. This is, in fact incorrect, I just had misunderstood the labels part. It is nt possible for a node not to have a label. It also do not make much sense to compare the label with the node name, as the node name is a renderable sequence. -- Pat
Re: [help-texinfo] IXIN 1.7 available
On Fri, Jan 18, 2013 at 02:40:42AM +0100, Patrice Dumas wrote: On Fri, Jan 11, 2013 at 10:22:25AM +0100, Thien-Thi Nguyen wrote: Float should also have a number pre-filled. This is currently missing in the XML output. Then to match an index entry in the document to an index entry in the dts list, the index name and numbere in index is taken from the XML (in fact the number is not there for now, but I'll add it). Those 2 elements have been added to the (S)XML. I'll now take a stab at a first IXIN output implementation. I'll do it with some abstraction, such that other output format than lisp-like may be output with the same information structure, for instance XML. -- Pat
Re: [help-texinfo] IXIN 1.7 available
Other comments * for lang, why not using a string, taking whatever is the default (in general en and not en_US), and instead of a list using like en_US, (or maybe - if there is no language because of an error somewhere, not sure this may happen)? * for title, there are 2 possibilities (in HTML), fulltitle and simpletitle. fulltitle is 'settitle', 'title', 'shorttitlepage', 'top' and then first 'titlefont'. simpletitle is 'settitle', 'shorttitlepage'. What should be used here? * in invitations should the CATEGORY really be a string, and not a renderable sequence? in invitations ENTRY, the title is optional, so I think that it could be -, but otherwise should be a renderable sequence. The node could be handled like any (external) node. Which leads to how should (external) nodes be represented? I propose something along (label manual name) where label is a node label, A string whose characters are strictly from the set [-_A-Za-z0-9]. manual is - for an internal node, and a string, the manual name (more or less the manual files) for an external node. name is a renderable holding the node name. * I am not sure the vars are needed. If they are, I think that the name should be a string and not an identifier. * for the toc, summarycontents and shortcontents are the same, so I think only one should be expected, here. Also I think that it may make sense to have a bit more information, that is the node ids the contents or shortcontents appears in. So something like ((contents [nid...]) (shortcontents [nid...])) As I already said, I think that @documentdescription should be meta, along with copying and titlepage. I'll certainly have more comments as I implement the ixin format. Do you wnat patches against the specification? -- Pat
Re: [help-texinfo] IXIN 1.7 available
On Fri, Jan 11, 2013 at 10:22:25AM +0100, Thien-Thi Nguyen wrote: ‘spec/ixin.texi’ is The IXIN Chronicles, a document that defines the file format and provides related info. There are various output formats, including .info, .pdf and .ixin. Some more comments on the format. In the 'flosets-index' the normalized type should also be present. It allows to link a float to the listoffloat, through the 'flosets-index' the to the node. The node label is missing in the 'node index'. In the node index, the next/prev/up directions may point to other nodes. For example @node mynode, (gcc) points to the gcc manual. Float should also have a number pre-filled. This is currently missing in the XML output. Also a label, if present. All the references should, in my opinion, be resolved thanks to information already present in the tree. * nodes/anchors/floats: the label. * index entry: index name and number in the index. * image/blob: file name as identifier. For the index entries I propose to have 2 informations available: 1. The list of sorted index entries, as already described in 'document-term sets'. Two things should be changed for that list, in my opinion. First sorting should not be specified. Thus, I think that The entries in each DTS is sorted alphabetically, case insensitively. should be removed. Second an index term can only happen in one node, thus 'nid' should be A node identifer in which term appears, may be empty if the entry do not appear in a node. 2. The second information is a list, for each index type, in order of appearance, of the index entries containing the place of the index entry in the sorted list described in 'document-term sets'. So for example, if we have @node Top @cindex B @cindex A The first list is (2 r) ((A) 0) ((B) 0) The second list is (2 1) Then to match an index entry in the document to an index entry in the dts list, the index name and numbere in index is taken from the XML (in fact the number is not there for now, but I'll add it). The place in the sorted list is found using the second list. Then the index entry number in the dts list is known. Some things are still missing, but nothing very important. For instance, if there was some @raise/@lowersections, it should certainly be in the sectioning tree. @documentdescription should also certainly be in the xid. Merged indices information is in the tree and I think that in some places it could be specified that the index name is the index name the index is merged to. Also the @abbrev and @acronym may deserve their own index, to associate to the explanation of the @abbrev / @acronym that appeared before. -- Pat
Re: [help-texinfo] IXIN 1.7 available
On Fri, Jan 11, 2013 at 10:22:25AM +0100, Thien-Thi Nguyen wrote: ‘spec/ixin.texi’ is The IXIN Chronicles, a document that defines the file format and provides related info. There are various output formats, including .info, .pdf and .ixin. Another comment, I think it would be better if you could do without the ixin new element. Instead, I think that a map that translate labels to node number could be used, and then the labels that are already in the tree could be used, avoiding the need to add a new element. Something like that would in any case be needed for cross references, so it wouldn't hurt much to use it for internal references too. -- Pat
Re: [help-texinfo] IXIN 1.7 available
Hello, I have added a SXML backend based on the XML one. You can test it with texi2any --set SXML=1 myfile.texi There is no header, no comments. How should comments be handled? Entities are output as normal elements, like (textlsquo (@)) There is an extraneous space after string before element with content closing parentheses. Getting rid of it should not be easy, but it is not a big deal in my opinion. There is no indentation at all, but I don't think this is problematic either. -- Pat
Re: [help-texinfo] IXIN 1.7 available
() Patrice Dumas pertu...@free.fr
() Tue, 15 Jan 2013 19:52:57 +0100
On Fri, Jan 11, 2013 at 10:22:25AM +0100, Thien-Thi Nguyen wrote:
‘spec/ixin.texi’ is The IXIN Chronicles, a document that
defines the file format and provides related info. There
are various output formats, including .info, .pdf and .ixin.
Another comment, I think it would be better if you could do without
the ixin new element. Instead, I think that a map that translate
labels to node number could be used, and then the labels that are
already in the tree could be used, avoiding the need to add a new
element.
Something like that would in any case be needed for cross references,
so it wouldn't hurt much to use it for internal references too.
I'm sorry i don't follow. Are you referring to ‘ixcc’, which is not an
element but an attribute? For example:
(image (@ (where inline) (ixcc (blob 0)))
(imagefile (@) logo))
which corresponds to the XML:
image where=inline ixcc=(blob 0)
imagefilelogo/imagefile
/image
The ixcc targets include not just nodes (family ‘node’) but also DTS
(family ‘(dts NAME)’), flosets (family ‘(floset TYPE)’) and blobs-index
entries (family ‘blob’, as in the example). If you play around w/ the
.ixin files using spit.el, you can see these various families (mostly
nodes and DTS) highlighted. I think spec/{ixin,z4}.ixin are the only
ones that have blob and floset families:
$ find . -name '*.ixin' | xargs grep -nHE -e 'ixcc.+(blob|floset)'
./spec/ixin.ixin:460: (image (@ (where inline) (ixcc (blob 0)))
./spec/ixin.ixin:620: (float (@ (type Figure) (ixcc ((floset
Figure) 0)))
./spec/ixin.ixin:639: (float (@ (type Figure) (ixcc ((floset
Figure) 1)))
./spec/z4.ixin:407: (ixcc (blob 0)))
./spec/z4.ixin:529: (float (@ (ixcc ((floset Figure) 0)))
./spec/z4.ixin:547: (float (@ (ixcc ((floset Figure) 1)))
--
Thien-Thi Nguyen . GPG key: 4C807502
. NB: ttn at glug dot org is not me .
. (and has not been since 2007 or so) .
.ACCEPT NO SUBSTITUTES .
... please send technical questions to mailing lists ...
pgprMTUQjqv4X.pgp
Description: PGP signature
Re: [help-texinfo] IXIN 1.7 available
On Tue, Jan 15, 2013 at 10:18:51PM +, Karl Berry wrote: I have added a SXML backend based on the XML one. texi2any --set SXML=1 myfile.texi 1) maybe the name should be IXIN rather than SXML? I thought SXML is just a generic name for XML written in sexprs. Or am I wrong? You are right that SXML just a generic name for XML written in sexprs. But right now what the SXML=1 produces is not IXIN, IXIN also has tables to map nodes/floats/index entries/nodes, blobs for image files... It only produces the SXML that is needed by IXIN. (For the same reason, we should not have named the TexinfoXML output just XML, but it's too late now. Let's not compound the mistake.) So I guess, it is TexinfoSXML then. So, I will change the --set to TEXINFOSXML. I will also change the perl module name. I could even change the XML perl module name to TexinfoXML, that would make sense. And also the format could be called 'texinfoxml' instead of simply 'xml' (the format name is seldom used, though). 2) Should there be an --ixin option, like all the other output formats? Certainly, when it is ready... 3) Should we add this to the documentation and make it an official part of 5.0, or do you (both) think that is still premature? I don't mean that every detail has to be nailed down and put in stone, but rather that the basic idea of IXIN output be mentioned. It is premature, the TexinfoSXML is not that much worth mentioning, in my opinion. Well, it should be documented, but just like the 'special' outputs (DEBUGTREE, TEXTCONTENT...). -- Pat
Re: [help-texinfo] IXIN 1.7 available
() Patrice Dumas pertu...@free.fr
() Sun, 13 Jan 2013 22:14:19 +0100
I have read the specification, looks good, none of the ??? looked
like stumbling blocks.
Cool, thanks. The SETTINGS representation (re)design will benefit from
scrutiny in the next release, for sure.
Using mime types for images seems to me the way to go, it could be
easily extended then. The image formats selected could be as large
as what we select for docbook or as narrow as what is selected for
HTML.
Currently, the MIME type is a symbol, which precludes things like, e.g.,
text/html; charset=UTF-8, which has semicolon and space. Is that OK?
I can't imagine a blob of ‘text’ (even SVG would be ‘image/svg+xml’),
which is the only MAJOR that seems to require MIME attributes like
‘charset’, on one hand, but on the other hand, my imagination has been
shown inadequate many times before... I really hate the idea of using a
string, though. Maybe the MIME type could be represented as:
(MAJOR MINOR [ATTRIBUTES...])
where ATTRIBUTES... is a plist (alternating symbolic NAME, and string
VALUE). Some examples:
(image png)
(image jpeg)
(image svg+xml)
(text html charset US-ASCII foo bar baz quux)
What do you think? Any thoughts on encoding besides ‘base64’?
Now turning to some implementation, I have looked over the
Data::Stag::SxprWriter code, and it is so simple that I think it
would be better to modify the XML texi2any backend to be able to
directly output SXML.
OK. I'll drop ‘SxprWriter’ mumblings in the next release, then.
One thing that is not clear to me is what should be done for
entities. If they are expanded (as specified in the DTD, for
example), in some cases, there is some information lost.
Could you give an example of lost information?
In my opinion it would be better to keep the entity information in
the SXML. Would there be some way to specify atoms that correspond
with entity?
For example:
@copyright{} @error{}
Could be like
(para (@) (copyright) (errorglyph))
but it doesn't look very correct. An idea on what should be done for
that?
How about:
(glyph (@ (name copyright)))
(glyph (@ (name errorglyph)))
This means this renderable sequence, for instance, changes from:
(Copyright copyright; 2013)
to:
(Copyright
(glyph (@ (name copyright)))
2013)
I presume the some information you mention above can be properly
represented in the attribute list of element ‘glyph’, or in its body.
--
Thien-Thi Nguyen . GPG key: 4C807502
. NB: ttn at glug dot org is not me .
. (and has not been since 2007 or so) .
.ACCEPT NO SUBSTITUTES .
... please send technical questions to mailing lists ...
pgpAahtoktMh5.pgp
Description: PGP signature
