[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [help-texinfo] IXIN 1.7 available

From: Thien-Thi Nguyen
Subject: Re: [help-texinfo] IXIN 1.7 available
Date: Mon, 14 Jan 2013 09:49:52 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

() Patrice Dumas <address@hidden>
() 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

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:


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

How about:

  (glyph (@ (name "copyright")))
  (glyph (@ (name "errorglyph")))

This means this renderable sequence, for instance, changes from:

  ("Copyright &copyright; 2013")


  ("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 ...........

Attachment: pgpyHSxX6PBo2.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]