[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
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 ©right; 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 ...........
pgpyHSxX6PBo2.pgp
Description: PGP signature