Re: [help-texinfo] Newbie seeks feedback on a Texinfo learning project
() Eli Zaretskii <e...@gnu.org> () Fri, 16 Sep 2016 17:06:35 +0300 . Also try to avoid closely located index entries that begin the same, like this: @cindex How to Download a RedHat Package @cindex How to Download a Fedora Package Instead, either make a single index entry, or remove the "How to Download" from the entries. Another approach: Move the general bit after the specific bit. For example: @cindex RedHat Package, How to Download @cindex Fedora Package, How to Download Personally, i'd go one step further and use a gerund: @cindex RedHat package, downloading @cindex Fedora package, downloading (This example also shows downcased non-proper-noun words.) -- Thien-Thi Nguyen --- (defun responsep (type via) (case type (technical (eq 'mailing-list via)) ...)) 748E A0E8 1CB8 A748 9BFA --- 6CE4 6703 2224 4C80 7502 signature.asc Description: PGP signature
[help-texinfo] attribute ‘number’
I see that makeinfo 5.2 produces XML with the ‘number’ attribute
for index entry elements, e.g. (translated to SXML):
(cindex
(@ (index cp) (spaces ))
(indexterm
(@ (index cp) (number 1))
non-recommendation))
This is from the fragment:
my $number;
unless (_ignore_global_commands($self)) {
$number = (defined($index-{'index_entries'})
? (scalar(@{$index-{'index_entries'}}) + 1)
: 1);
}
my $index_entry = { [...]
'number' = $number,
};
in tp/Texinfo/Parser.pm, which IIUC associates an incrementing
integer w/ each ‘indexterm’ element (for a particular index),
but only if ‘_ignore_global_commands ($self)’ evals not true.
I see the source (also in Parser.pm) of that subroutine is:
# return true if effect of global commands should be ignored.
sub _ignore_global_commands($)
{
my $self = shift;
return !$self-{'expanded_formats_stack'}-[-1];
}
but before i wade in fully, i'll just ask quickly here: What
must the user do (in terms of command-line options) to affect
the ‘expanded_formats_stack’? (I'm trying to figure out what
the IXIN stance towards attribute ‘number’ should be: ignore,
require, support but not require. I didn't find any mention of
‘number’ in the NEWS file, although i did find ‘@elem number’ in
node Customizing Output File Names in doc/texi2oldapi.texi,
which seems obsolete or on its way to being so...)
--
Thien-Thi Nguyen
GPG key: 4C807502
(if you're human and you know it)
read my lisp: (responsep (questions 'technical)
(not (via 'mailing-list)))
= nil
signature.asc
Description: PGP signature
Re: [help-texinfo] texinfo sources now in svn
() Patrice Dumas pertu...@free.fr () Thu, 28 Feb 2013 19:00:02 +0100 On Thu, Feb 28, 2013 at 09:05:36AM +0100, Thien-Thi Nguyen wrote: It seems i spoke too soon. [PEBKAC w/ svn co.] In fact you only need the trunk branch. With svn that would be: svn co svn://svn.savannah.gnu.org/texinfo/trunk texinfo It is much less than 1.3GiB (for a fresh checkout): $ du -shx texinfo 225Mtexinfo It takes some time to checkout, though (real 2m31.220s in my case). Thanks. I see: $ du -shx texinfo 242M texinfo and it took approximately 4.5 minutes. I'll look into playing w/ IXIN support in Texinfo now. Any tips on where to start? -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) = nil signature.asc Description: PGP signature
Re: [help-texinfo] IXIN 1.8 available
() Patrice Dumas pertu...@free.fr () Sun, 24 Feb 2013 19:20:47 +0100 On Sat, Feb 16, 2013 at 04:16:02PM +0100, Thien-Thi Nguyen wrote: - mkixin records blob lengths individually, not cumulatively Before, for two blobs of lengths A and B, BLOBS-INDEX would record lengths A and A+B. Regarding blobs indexing, I think that it would be better if there was a separate length and position. That way it could be possible to intersped blobs with text, for example text that describes the blob and would be used as a comment. For example truc.png jsfdjkfsdkjfsdkjfsdjkfdsjfsd machin.jpg mqdsmlsdqljsqlmdjqmljdsmjlqsdmljsdmldsqlmqjdsdqslm So the index would be 2 informations, the length of the blob and an information that allows to find the blob, either the absolute position in the blobs, or the total length (blob+following text between blobs). Interspersing blobs with text seems like a step backward to me. The current (lazy) design is nicer to low-resource renderers. Re redundancy (position info), that suggests that there should be some kind of integrity-checking tool. Hmmm. FYI, IXIN source is now in a public repo, and there is also a dedicated mailing list (reachable from the project page): http://git.savannah.gnu.org/cgit/ixin.git?h=p http://savannah.nongnu.org/projects/ixin I don't mind continuing its discussion here, of course. -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it) read my lisp: (responsep (questions 'technical) (not (via 'mailing-list))) = nil signature.asc Description: PGP signature
Re: [help-texinfo] How to make info fail if the topic is not found?
() Arne Babenhauserheide (IMK) arne.babenhauserhe...@kit.edu () Wed, 10 Apr 2013 10:32:10 +0200 Is there a config option or so to just fail when info gets a nonexisting topic? Or even a commandline flag? I think ‘-f’ is what you seek. For example: $ alias inf='info -f' $ inf no-such ; echo $? info: no-such: No such file or directory 1 $ inf emacs ; echo $? [session w/ emacs (type ‘q’)] 0 remember the line of the cursor in a given node? Try typing ‘l’ instead of ‘u’. -- Thien-Thi Nguyen GPG key: 4C807502 pgp2PsPT7S0w4.pgp Description: PGP signature
Re: [help-texinfo] Changing background color of the 'verbatim' environment
() Jason Massey janixs...@gmail.com () Thu, 13 Sep 2012 09:48:58 -0400 I have produced a handful of in-depth manuals at my job [...] [tale of leaving texinfo and returning later] Yeah, that's the breaks when you learn to program computers... you get to experience not only the output, but also the input, and the twisted paths, and moreover, all of the above, manifested by the different people around you, who may or may not share sensibilities or direction. That's why XML (et al) is so sick and wrong. Only humans could do that (to themselves and each other :-D). *So, I guess what I am saying is that I hope that Texinfo does not meander into XML-verbosity.* Actually, I'm begging that it does not. Check out IXIN http://www.gnuvola.org/software/ixin/ and send feedback before it's too late! (You might have to try Emacs for a full taste.) -- Thien-Thi Nguyen GPG key: 4C807502 pgpL6d27720Jy.pgp Description: PGP signature
Re: [help-texinfo] texinfo sources now in svn
() Thien-Thi Nguyen t...@gnuvola.org () Fri, 22 Feb 2013 08:58:26 +0100 I had delayed looking at the new generated-by-Perl IXIN stuff because of CVS antipathy. Now theres no more excuse. :-D It seems i spoke too soon. The svn co command consumed all disk space and memory on my computer before exiting failurefully. As a workaround, i installed git-svn and did: $ mkdir texinfo $ cd texinfo $ git svn init svn://svn.savannah.gnu.org/texinfo $ git svn fetch which required about seven hours and five manual restarts to complete (interruptions were due to connection timeout), w/ a 1.3GiB footprint. So, now i see a bunch of directories many of them named texinfo. Which one contains the IXIN hacking? [cc redirected] -- 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 ... pgp_ecl3BVwka.pgp Description: PGP signature
[help-texinfo] IXIN 1.8 available
. Empty SXML
attribute lists are discarded, or represented as a single ‘-’
(hyphen) should a child element begin on the same line (rare).
Non-empty SXML attribute lists are highlighted, and the
surrounding parens and initial ‘@’ deleted.
- ‘t’ bound to ‘toggle-truncate-lines’
This makes it easier to switch attention from structure to
content and back.
- ‘s’ (aka ‘spit-%show’) also displays settings / tweaks
If at node beginning (more precisely, prior to the start), there
are settings or tweaks in effect, these are now displayed
ordered most recent to most past, with same-NAMEd past entries
suppressed, one per line:
NAME (N) [VALUE...]
N, usually 1 but not always, is the count of VALUEs.
The type of each VALUE depends on NAME.
Note that you need to ‘M-m’ and ‘M-i’ to cache ‘settings’ and
‘tweaks’ so that they can be be in effect. For example, here
is how a spit session for spec/ixin.ixin might go:
s ; see ‘Top’ w/o settings
M-m; cache ‘settings’
s ; same, now w/ settings: document{language,encoding}
; headings, every{heading,footing}
M-i; cache ‘tweaks’
s ; same as before (no tweaks yet in effect)
6 * n ; arrive at ‘Release Notes’
s ; similar to before (still no tweaks in effect)
n ; arrive at ‘Program and Doubt Index’
s ; see also ‘paragraphindent (1) asis’
[ ; arrive at ‘version X.Y’
s ; see ‘paragraphindent (1) 0’
Obviously a real (non-proof-of-concept) renderer would handle
this caching transparently.
tarball, etc, in dir:
http://www.gnuvola.org/software/ixin/
atom feed:
http://www.gnuvola.org/NEWS.atom
--
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 ...
pgpxMyo74ESS6.pgp
Description: PGP signature
Re: [help-texinfo] Unicode line drawing chars in pdf output
() James Cloos cl...@jhcloos.com () Fri, 18 Jan 2013 20:38:44 -0500 FontForge kept crashing (SEGV) when I tried to work out a recipe. I've recently recompiled it w/ less optimization and that seems to avoid the crashes. The basic idea it to: [many steps] Thanks for listing these steps. Which shows that this'll need more though. Yeah, that does seem intimidating. I have installed debian's fontforge package (version 0.0.20100501-5) -- hopefully it is sufficient for this. [other tips] OK, i'll keep those in mind. It seems it is not as trivial as I recalled. If i stumble upon something i'll follow up here. -- 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 ... pgpUEWTMk8Fom.pgp Description: PGP signature
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
() 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
[help-texinfo] IXIN 1.7 available
., for family ‘(floatset TYPE)’, the coordinate is anyway decorated with the family in red, the position yellow. Relatedly, typing ‘tab’ or ‘backtab’ now runs command ‘forward-button’ or ‘backward-button’, respectively. - ‘C-M-d’ (aka ‘spit-%list-dts’) deleted The output for this command is largely redundant w/ that of ‘M-d’ (aka ‘spit-%dump-dts’). - image blobs displayed inline E.g., spec/ixin.ixin node 1 (Introduction) shows the logo. - spec document renamed: The IXIN Chronicles Its scope is now expanded beyond the spec proper to include other stuff (i.e., opportunities to exercise the utils), such as invocation (usage) and implementation notes for the utilities, interesting character sequences from d/prob.xml, how to compute the node base and blob base, etc. Relatedly, there are now many more terms in the indices. - mkixin uses temporary dir for temporary files This means you can use make -j in d/, now. Previously, the temporary filenames were hardcoded, confusing peer processes, and resulting in corrupted output. tarball, etc, in dir: http://www.gnuvola.org/software/ixin/ atom feed: http://www.gnuvola.org/NEWS.atom -- 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 ... pgp_j_FZ2vnjy.pgp Description: PGP signature
Re: [help-texinfo] Unicode line drawing chars in pdf output
() James Cloos cl...@jhcloos.com () Mon, 07 Jan 2013 16:35:33 -0500 OTOH, if you really want line drawing fonts, using the DejaVu Mono src to generate a type1 font would be trivial. FF has support to narrow the glyphs in a reasonable manner to match each version of cmtt. (cmtt8 is 531/1000, cmtt9 and cmtt10 are 525/1000 and cmtt12 is 514/1000. dejavu mono, to match courier's 600/1000, is 1233/2048.) The word trivial is tantalizing, but i have no experience whatsoever. I suppose FF stands for Font Forge. Is that right? Any suggestions for a font newbie to ramp-up on these terms / algorithms very welcome. -- 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 ... pgpSTIYtNeLBq.pgp Description: PGP signature
Re: [help-texinfo] Changing background color of the 'verbatim' environment
() Patrice Dumas pertu...@free.fr () Wed, 19 Dec 2012 19:34:37 +0100 Something important is still missing, the support for cross ref within nodes, to @float or @anchor. For that you need to associate a normalized label to the position in the node. There should also be a table associating normalized labels to nodes, for external references. Normalized labels are unique strings associated with node names. They are used for HTML cross references, but are useful in other contexts too, I think you should also use that. You don't need to say much about those strings except that they are uniquely associated to labels. They are described in 'HTML Xref'. They are not available in the crossref commands in XML for now, but I think they should be. They are associated to the label commands already. OK, i'll work on that for IXIN 1.5. (BTW, IXIN 1.4 is now available.) Also on my mind now are internal references, to replace indexed items (nodes, dts, floats, images (maybe)) w/ a INIX reference, using a INIX coordinate'. For example, in d/ixin.ixin node 1, instead of: (indexterm (@ (index cp)) origin, idea) we could have (ixref (@ (ixcoord (dts cp 24 which denotes DTS ‘cp’, entry 24 (line 109). Generally, the value of an ‘ixcoord’ attribute is a list (in string form, to be proper SXML) that specifies, from most general to most specific, the particular indexed object. The last element is always a non-negative integer. E.g.: (node 0) ; Top node (floset Figure 1) ; second entry of the ‘Figure’ floset (blob image 0) ; logo The last example is tentative only, as i'm not sure the best way to handle images (see IXIN 1.4 README for options and current approach). Anyway, there are a bunch of ‘???’ now in the spec doc. If you have any thoughts on those, i'd very much appreciate hearing them. -- 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 ... pgp0GCZIq4K0c.pgp Description: PGP signature
Re: [help-texinfo] Changing background color of the 'verbatim' environment
() Thien-Thi Nguyen t...@gnuvola.org () Wed, 12 Dec 2012 06:57:31 +0100 this requires rendering programs to handle high N, but that's not so onerous (and usually N is (lamentably) not that high, anyway). On second thought, Emacs doesn't handle bignums (w/o Calc), oh well. Another idea is to keep the per-TX form and use some per-entry notation to distinguish those requiring the inverse face. Something like: (TX-COUNT r) (- access 1) ; note ‘-’ in car (around, fooling 1) (- quit 2) ; likewise This is easier on Emacs. Since we now have a per-TX form, anyway, we can move TX-COUNT into it from top-level COUNTS to reduce bloat there. -- 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 ... pgp1xv1kam7bF.pgp Description: PGP signature
Re: [help-texinfo] Changing background color of the 'verbatim' environment
() k...@freefriends.org (Karl Berry) () Thu, 13 Dec 2012 00:02:33 GMT such that rendering programs DTRT for both ‘foo’ and ‘bar’. I don't see the problem, in principle. The information about what font should be used for what index entry is completely determined (and deterministic) by other known information. As Patrice says, though, it could be inconvenient to trace back the @syn*indexes and @def*indexes. I have no objection to adding the info explicitly in the XML (or whatever) output. Yes. The problem is not in principle, but in practice: How to summarize the known information for efficient access. Furthermore, it's not a problem of Texinfo per se, but of the still-evolving .ixin file format. Whimsical while-coffee-penetrates-brain aside: Trees are beautiful, and hanging them by the leaves is almost an unbearable violence, so we try to be merciful in our transformations. Too bad computers understand only the the transformations and not the beauty. -- 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 ... pgpreoBNsLpEv.pgp Description: PGP signature
Re: [help-texinfo] Changing background color of the 'verbatim' environment
() Patrice Dumas pertu...@free.fr () Tue, 4 Dec 2012 22:42:11 +0100 (NAME LENGTH NEXT PREV UP [TWEAKS...]) Exactly. OK, as soon as i figure out the associated types, and how to handle the variables as directives txicodequotebacktick, txicodequoteundirected, and txideftypefnnl, then these will go in. Could you please rview the IXIN 1.3 README groupings and let me know if i'm on the right track? I still don't really get [gzip/base64]. Isn't Base64 encoded with offsets also easy to corrupt? [plain text is better] You have convinced me. As of IXIN 1.3, that weirdness is gone. -- 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 ... pgplAOqbsIW9q.pgp Description: PGP signature
Re: [help-texinfo] Changing background color of the 'verbatim' environment
() k...@freefriends.org (Karl Berry) () Tue, 11 Dec 2012 22:31:43 GMT important, doubt is how to make sure that functions in the ‘cp’ index (say) are formatted with ‘@tt’ as opposed to ‘@r’? The cp index is formatted with the @r font. All other predefined indexes are formatted with the @code font. Right. That information doesn't seem to be captured anywhere. Indexes using @r vs. @tt is part of the definition of Texinfo, just like anything else, so it's not something that would be part of an xml-or-whatever file as far as I can see. Yes, that's the issue. How to carry into the .ixin format enough information, given (for example): @syncodeindex fn cp ... @defun foo @end defun ... @cindex bar such that rendering programs DTRT for both ‘foo’ and ‘bar’. Currently, some inline formatting is saved (such as ‘code’ -- see alive.ixin:54), but that's just part of what's needed. -- 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 ... pgpLo8fg1g7H7.pgp Description: PGP signature
Re: [help-texinfo] Changing background color of the 'verbatim' environment
() Patrice Dumas pertu...@free.fr () Sat, 1 Dec 2012 09:27:20 +0100 Afer ore thinking, and answering to myself, I think that the most efficient would certainly be to have the value at the end of the preamble for those commands in the META section, because, in most cases this is not changed in the document, and add in the index the state at the beginning of the node only if it differs from the value at the end of the preamble. Hmmm, if i understand correctly, you want to maintain VARS and SETTINGS in META, but modify INDEX entries to go from: (NAME LENGTH NEXT PREV UP) to: (NAME LENGTH NEXT PREV UP [TWEAKS...]) where each TWEAK could override some element in VARS or SETTINGS. In this case, there need not be any TWEAKs list at file top-level. Does that sound right? I think that would work, too. Is the point having everything in only one file? After thinking a bit about it, indeed having everything in one file would be practical. Yes. But I can't see what a base64-encoding and gzipped representation adds. A plain SXML text representation should certainly be better, with beginning and end of node indexes. For figures, base64-encoded gzipped would make sense, though. Unfortunately, plain text is easier to corrupt undetectably. Too, piping plain text around requires everyone to take pains about encoding issues on the outside of their program as well as on the inside (which is hard enough, look at all the kludges/bugfixes succumbed by a2ixin!). Actually, a2ixin is not a good example -- its role is to mimic some future makeinfo, which we KNOW will DTRT :-D, rather than a renderer. Compression is good, generally, anyway. On the other hand, base64 indeed is superfluous. I think i added that mostly for aesthetics. (But then again, it does help keep text encoding issues internal.) -- 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 ... pgpymSKuAnPiW.pgp Description: PGP signature
Re: [help-texinfo] Changing background color of the 'verbatim' environment
() Patrice Dumas pertu...@free.fr
() Sat, 15 Sep 2012 21:05:17 +0200
On Thu, Sep 13, 2012 at 11:25:09PM +0200, Thien-Thi Nguyen wrote:
Exactly; a separate (very simple) parser for reading a plist is
needed. Attributes are stuff that makeinfo acknowledges exists,
checks for syntax errors, but doesn't otherwise further act upon
(except for a few special cases).
It should not even check that there are syntax errors or not, except
if doing a format that really uses what is passed, that is, in a
downstream processing.
I think that this should better be put in raw formatting. If
this is for processor of format foo, it is possible to add
anything with (but notice that @ has to be escaped)
@inlieraw{foo, bg dark blue fg fireengine red
phase-of-the-moon
one, or \more\ (depending)
texi:id the first @@example example}
It is not for format foo specifically, it is just general style
info, or even notations. Whether or not the author succeeds in
communicating w/ particular processor foo is not a concern for
makeinfo.
foo do not need to ba a true format. It could be a 'pseudo-format'
that allows to flag annotations, for example it could be
plistannotations
Translated to SXML:
(inlineraw
(inlinerawformat foo)
(inlinerawcontent
(@ (spaces )
(bg quot;dark bluequot;)
(fg quot;fireengine redquot;)
(phase-of-the-moon quot;one, or \quot;more\quot;
(depending)quot;)
(texi:id quot;the first arobase;example examplequot;
which would be fine, if it were attached to ‘example’, not specific
to any format, and strings interpreted as in C:
Strings should be interpreted by the downstream processor. For
makeinfo it is just some plain text that is passed down appropriately
quoted depending on the output format, so here I think it should be
up to the dowstream processor to transform this XML to something
else.
Now, the association with the previous or next element/command, that,
indeed, may be of use for the processor. On that subject, I don't
have a clear idea of what could be done by makeinfo to help a
processor associate an information, which may be in @inlineraw, for
example, or somewhere else, to the next (or previous, or parent)
Texinfo construct.
The simplest, from the makeinfo point of view, would be not to do
anything, and the downstream processor would determine the
association based on the tree (in whatever format this tree is used
by the downstream processor, XML, s-exps tree, internal perl
tree...). Should there be something more done, and if so in which
format?
Since this last exchange a couple months ago, i've tried to answer in
which format by playing w/ code. (I agree that makeinfo should be
hands-off, for the most part, btw.) If you get a chance, please see:
http://www.gnuvola.org/software/ixin/
I think the priority is to define the container shape, which is what
IXIN 1.0 aims to do; precise design / interpretation of the (S)XML-ish
contents can be done later. What do you think?
--
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 ...
pgpggzB9c513l.pgp
Description: PGP signature
Re: [help-texinfo] Changing background color of the 'verbatim' environment
() k...@freefriends.org (Karl Berry) () Wed, 12 Sep 2012 22:01:34 GMT Breaking @cartouche over pages is TeXnically possible. So is supporting background colors for @example / @verbatim. It's just that I personally am never going to work on either one -- way too much effort for way too little return. Of course, I'd happily accept clean patches for them. Another approach is to define a syntax to associate key/value pairs w/ any particular environment. This could map to ‘class’ attributes for HTML output, and would anyway be available to the (S)XML output for further processing. Something like: @example (bg dark blue fg fireengine red phase-of-the-moon one, or \more\ (depending) texi:id the first @example example) ... @end example @verbatim (texi:inherit the first @example example) ... @end verbatim IOW, keys are symbols, values are strings, elements are separated by whitespace, and the lot is enclosed in parentheses -- classic plist. Info output can simply ignore that noise (or not). Some of the keys could be reserved for special handling, such as those whose names begin with texi:. Yeah, i know this is getting ugly real fast, but figure (sometimes) some beauty can be achieved by confining ugly and ignoring it. -- 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 ... pgpe0DU6nw4uP.pgp Description: PGP signature
Re: [help-texinfo] Changing background color of the 'verbatim' environment
() Jason Massey janixs...@gmail.com () Thu, 13 Sep 2012 09:48:58 -0400 [the horror the horror] Yeah, XML is suboptimal. SXML is slightly better, but still rotten. *So, I guess what I am saying is that I hope that Texinfo does not meander into XML-verbosity.* Actually, I'm begging that it does not. I agree completely; the suggestion was made w/ a strict anti-meandering mindset. The idea is to allow pass-through specification, reserving the fewest special-handling specifications (w/ semantic perturbations) possible. Essentially, makeinfo says, You want to express your style? Fine, no skin off my nose. I'll let the downstream renderer know. If your specs confuse the downstream renderer, don't complain to me! Don't GI if you don't want GO! (See http://foldoc.org/GIGO.) Re verbosity, you can hardly get simpler than a Lisp plist. But that's besides the point (which is explained above). The document model already includes nodes w/ certain attributes (name, depth, relation to other nodes in the graph). The suggestion was to add pass-through attribute specification to environments, but the same idea could also be applied to the nodes (w/ strict anti-meandering mindset) themselves. The sooner makeinfo supports uniform pass-through specification, the sooner it can remove itself from the style-wishlist treadmill. -- Thien-Thi Nguyen . GPG key: 4C807502 pgpR3zliCYtQK.pgp Description: PGP signature
Re: [help-texinfo] Non ascii to pdf.
() to...@tuxteam.de () Sat, 7 Jan 2012 09:55:40 +0100 As I said, I'd glad to help: but lets us take this conversation off-list, because I guess it's off-topic here. Well, there is at least one detail that is pertinent: setting the input encoding in the .texi file. Personally, i prefer UTF-8 these days. E.g.: http://git.savannah.gnu.org/cgit/serveez.git/commit/?h=nextid=aef4673b9
Re: [help-texinfo] wish: type on separate (preceding) line
() k...@freefriends.org (Karl Berry) () Sat, 21 May 2011 23:04:23 GMT but it would be nice IMO to make it look like: void * [Function] svz_server_configure (svz servertype t * server, char * name, I've implemented a new option in texinfo.tex for this. The official command will be `@deftypefnnl on|off' (I'm open to better suggestions for the name), but you can test it with `@set txideftypefnnl'. I've committed a new texinfo.tex to Texinfo CVS. Before I push it out, can you easily try it from there? Also attaching a patch for posterity, no idea if it will apply to whatever texinfo.tex you have now. Also attaching my test file. (I think it looks very good, BTW, but I'm feeling too conservative to change the default.) Let me know, and thanks. Thanks for looking into and hacking on this. I confirm that the output looks good with texi2dvi --pdf --batch deftypegnu.txi and texinfo.tex 1.346 just downloaded from savannah. Likewise, real world testing looks good, too: http://www.gnuvola.org/tmp.zTXhhpwOxd/ (This directory will be deleted in a few days.)
Re: [help-texinfo] wish: type on separate (preceding) line
() k...@freefriends.org (Karl Berry) () Sat, 21 May 2011 23:04:23 GMT I've implemented a new option in texinfo.tex for this. The official command will be `@deftypefnnl on|off' (I'm open to better suggestions for the name), but you can test it with `@set txideftypefnnl'. That name sounds as good as any if this is a one-off kind of feature. If you think to apply the feature to other contexts (i have none in mind to suggest), maybe something like: @extrabreak CONTEXT on|off where CONTEXT is one of ‘deftype’, etc, would be better. For example, a weird (entirely hypothetical) context might be ‘typefn’, which breaks between the function name and its args, or even ‘eacharg’, which breaks between each arg. Anyway, just thinking aloud; looking forward to its final form for GNU Serveez...
Re: [help-texinfo] wish: type on separate (preceding) line
() k...@freefriends.org (Karl Berry) () Fri, 4 Mar 2011 01:06:58 GMT I'll see what I can do. Thanks for the report. [...] makeinfo wouldn't be the right place for such an option, rather it'll be a new style directive in the language (if I can get it to work). Cool. I look forward to testing this.
[help-texinfo] Re: two blank lines instead of one
() [EMAIL PROTECTED] (Karl Berry)
() Wed, 9 Apr 2008 12:09:46 -0500
I installed the following change, which ignores the remainder of the
@verbatim line (including the newline), as it should have been all
along. I hope there are no ill effects.
+ { /* Ignore the remainder of the @verbatim line. */
+char *junk;
+get_rest_of_line (0, junk);
+free (junk);
+ }
+
With makeinfo 4.11.96 i now see one blank line as expected.
Thanks!
thi
[help-texinfo] two blank lines instead of one
The attached texi file produces the attached info file with command makeinfo foo.texi, using: $ makeinfo --version makeinfo (GNU texinfo) 4.11.94 In the info file, there are no blank lines between b0 and v0. However, between b1 and v1 there are two blank lines, where i would have expected to see only one. Is there any way to get only one blank line between b1 and v1? thi foo.texi Description: TeXInfo document foo.info Description: Binary data
