Re: [help-texinfo] IXIN 1.7 available

2013-01-27 Thread Patrice Dumas
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

2013-01-26 Thread Patrice Dumas
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

2013-01-19 Thread Patrice Dumas
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

2013-01-19 Thread Patrice Dumas
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

2013-01-17 Thread Patrice Dumas
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

2013-01-15 Thread Patrice Dumas
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

2013-01-15 Thread Patrice Dumas
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

2013-01-15 Thread Thien-Thi Nguyen
() 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

2013-01-15 Thread Patrice Dumas
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

2013-01-14 Thread Thien-Thi Nguyen
() 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