Re: Deployment of images with an info doc
Le mardi 15 décembre 2009 à 00:32 +0100, jema...@gnu.org a écrit :
That would make it difficult to decouple the manuals after they get
installed. Having gnupdf-arch.texi looking into gnupdf-arch-figures/
and gnupdf-hg.texi looking into gnupdf-hg-figures/ makes it possible
to relocate/copy/delete a deployed manual in a easy way.
I understand your point. For LilyPond docs, we didn't decide to
decouple the manuals because they include a ton of images of music as
PNG graphics, so we prefer to save space using a single directory shared
by all HTML (both single-page and splitted versions) and Info manuals.
Incidentally the lilypond-doc Debian package is creating an empty
${info_dir}/lilypond directory. I will report this.
Thanks. In addition, you may want to mention that 'make all'
compiles info manuals without images, and info manuals with images are
compiled with 'make doc' and installed with 'make install-doc'. Looking
at the commands make issues to build these targets may help, more than
struggling with reading our horribly complicated makefiles.
Best,
John
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: Deployment of images with an info doc
Le dimanche 13 décembre 2009 à 00:28 +0100, jema...@gnu.org a écrit :
Ok, I will use that workaround, maintaining several sub directories in
doc/ for the different manuals.
This sounds suboptimal. Can't you use a common figures directory with a
name that includes the name of your package, e.g. gnupdf/ or
gnupdf-figures/?
Maybe we should suggest the maintainers to follow the same convention
too? As time passes more and more projects would want to deploy the
images for graphics-enabled info readers...
For LilyPond info documentation, make install-doc creates
${info_dir}/lilypond/, which is a symlink to the subdirectory of
isntalled HTML docs tree which contains the images.
Best
--
John Mandereau
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: Smart quote replacement in texi2pdf broken with nested @code and @warning / @w
Hi Karl,
On 2008/10/28 17:03 -0500, Karl Berry wrote:
Maybe we could make ` and ' active all the time, like and other
characters are now.
I changed texinfo.tex (in CVS and gnulib and
ftp://tug.org/tex/texinfo.tex) to do this, so your backticks should show
up universally now. Fingers crossed ...
Using latest texinfo.tex, TeX barfs on LilyPond learning manual in
English. Here's the relevant part of the log:
./lilypond-learning.cps:12: Missing number, treated as zero.
to be read again
\char
'...sname \relax '\else \char '15 \fi \else \char
'15 \fi
argument \xeatspaces {\char '
15 }
\tclose ...on \rawbackslash \plainfrenchspacing #1
}\null
\codex #1-\tclose {#1}
\endgroup
l.12 \entry {\code {\xeatspaces {\char '15 }}
}{13}
A number should have been here; I inserted `0'.
(If you can't figure out why I needed to see a number,
look up `weird error' in the index to The TeXbook.)
... and here are the first lines of lilypond-learning.cps:
\initial {!}
\entry {\code {\xeatspaces {!}}}{21}
\initial {#}
\entry {\code {\xeatspaces {#}}}{173}
\entry {\code {\xeatspaces {##f}}}{173}
\entry {\code {\xeatspaces {##t}}}{173}
\entry {\code {\xeatspaces {#'symbol}}}{174}
\initial {%}
\entry {\code {\xeatspaces {%}}}{16}
\entry {\code {\xeatspaces {%{\tt \char 123} ... %{\tt \char 125{16}
\initial {'}
\entry {\code {\xeatspaces {\char '15 }}}{13}
\initial {(}
\entry {\code {\xeatspaces {( ... )}}}{19}
If this isn't enough to investigate and fix this, let me know and I'll
try to provide a minimal Texinfo source that reproduces this.
Best,
John
Re: Bug of @ref
Hi Karl,
On 2008/10/22 13:40 -0500, Karl Berry wrote:
Follow @ref{NewFile} for information on the template processing.
And the preceeding `see' was appearing.
Please send your actual input, makeinfo invocation, and resulting output.
I do not get any see with @ref.
There is certainly no such see written in Info output file for a
@ref, but as far as I have experienced, Emacs Info reader adds this word
if it's not already present just before the cross-reference.
Best,
John
Re: texinfo supports non-English hyphenation
On 2008/10/13 06:05 +0200, Werner LEMBERG wrote: the CVS version of texinfo now supports non-English hyphenation! As far as I can see in 2.1.62 French, German and Spanish Learning Manuals, it already partially did before I updated texinfo.tex yesterday, although I'm not sure how some words are hyphenated, e.g. reescribi-endo in the introduction of Spanish Learning Manual. I didn't notice any hyphenation difference after updating texinfo.tex, but I guess TeXlive 2008 is needed to see improvements (Fedora 9 provides TeXlive 2007). It's certainly a good thing you added txi-LL.tex files, as people who build the docs may not have the latest versions of these files. Cheers, John
Re: Broken link at http://www.gnu.org/software/texinfo/
On 2008/07/10 18:32 -0500, Karl Berry wrote: John, I know you expressed concern about speed, but I guess I just find it hard to believe that it would matter that much. I agree speed is not an important criterion with today's computers, as text formatting doesn't require so much memory and computing resources; in this kind of software speed should come after e.g. good design, portability and maintability. texi2html is a bit slow on my 1.4 GHz CPU when it comes to compile LilyPond manuals (each manual is between 100 and 340 pages long), but the time it takes is still ridiculous compared to the time needed to build whole LilyPond documentation with music samples (more than 2 hours). And, perhaps texi2html could be sped up; probably not to the point of a compiled language, but it sounds like a heck of a lot less work than an entirely new implementation. I definitely agree. John
Re: Broken link at http://www.gnu.org/software/texinfo/
On 2008/07/11 02:28 +0200, Patrice Dumas wrote: If you want to go down this road, I would certainly need lots of help on the info backend since I don't know the format. If you are interested in using texi2html as a makeinfo replacement I could certainly commit to implement the docbook and xml backends. I don't want to push you, though, I am not sure that texi2html is the way to go. I'm willing to help with texi2html development if and only if it will replace makeinfo and become part of GNU; well, I don't mind about the technical way we go, but it would be definitely cool to have only one package to process Texinfo documents. Currently texi2html has a sort of replacement of gettext for internationalization. But using gettext instead of reinventing the wheel would certainly be nice, though I don't know how gettext is done in perl. It would be much simpler to use Gettext from the translators' point of view. According to CPAN search engine http://search.cpan.org/search?query=gettextmode=all potential packages for using Gettext inside Perl are perl-gettext 1.05 and Locale-Maketext-Gettext-1.26 Best, John
Re: Broken link at http://www.gnu.org/software/texinfo/
On 2008/07/11 10:46 +0200, Patrice Dumas wrote: I think it is worth mentionning the weaknesses of texi2html. I think that the most problematic one is the home made parser. It is not that complicated for the 2 first passes. But in the last pass, it gets very complicated. There is a stack with @-commands with braces and 'formats' (@table, @itemize, @cartouche) and, in parallel a state which holds document-wide informations, including some stacks, to know which format of each type is on the top for complicated imbrications. In the stack there are fake formats that are not really formats from a texinfo perspective but are important for nesting, like a definition body, a cell and lrow in a multitable. There are exceptions everywhere with complicated conditions on the state. Another complication is that formatting of some things may lead to nested formatting, like, for example, a footnote text in normal text. I don't know if it is because of a poor design of the parser (which was never designed, and never really redesigned when new texinfo language rules appeared) or because texinfo is intrinsically complicated, but it is quite messy and I am often lost in it. In case it wasn't clear from what I previously wrote, note that I haven't read texi2html code; I only skimmed a little through it, and I might understand that you are lost in it, when you have very long functions (1442 lines for rearrange_elements()). Maybe you have designed this purposely to save function calls, but I would be lost in this too if I had to maintain it: such huge control-flow blocks are hard to read. I'd like to explain in a few words the (still incomplete) design of my hypothetical project; if it's not implemented from scratch, it might help give ideas for improving portions of texi2html. However, it's late for me this evening |-), I'll come back with it within one week. Cheers, John
Re: Broken link at http://www.gnu.org/software/texinfo/
On 2008/07/08 09:32 +0200, Patrice Dumas wrote:
On Sat, Jul 05, 2008 at 10:35:42AM +0200, John Mandereau wrote:
1) clearly separating parsing from formatting,
2) using GUILE to store parsed Texinfo input, so one can write Scheme
code to play with this input,
3) making HTML output completely customizable (like texi2html), using
GUILE (like LilyPond),
In case it wasn't clear, texi2html does the 3 items (except that the
tree is not a GUILE tree, but a tree of perl references).
I'd be happy if texi2html completely replaced makeinfo, except that
using an interpreted language in all 3 steps makes it run significantly
slower, hence my starting effort to write an implementation with a
parser written in a compiled language.
If you want to have a look at how things are done in texi2html, there
are 2 things that I think should be dropped from a texinfo converter,
namely the index splitting, and the possibility to have things like
@emph{Bla.
New paragraph.}
Are you sure it's a good idea to drop these features?
I am the main and most of the time only author of the code that does the
parsing of texinfo (though not necessarily the regexp), and I can put
any piece of my code in the public domain if you want to reuse/translate
it.
Thank you :-) I haven't read texi2html code in detail, but this probably
helps.
Best,
John
Re: Broken link at http://www.gnu.org/software/texinfo/
On 2008/07/07 19:58 -0500, Karl Berry wrote: On the other hand, my experience with makeinfo is showing me that without some consideration of backward compatibility as you go along, it is too hard to just tack on later. You end up with what makeinfo is now -- a collection of warts. Anyway. This is the kind of thing that becomes clearer in the actual development than in talking about it, IMHO. I'd like to put all backward compatibility warts in the parser, so clean formatting rules can be written. I'm not sure it's at all possible, I may be dreaming :-) a Texinfo parser that builds data trees that represent Texinfo documents, to play with for managing translations. Even if I (or we) Sorry, I don't see how it's relevant to translations. You're thinking of some gettext-like thing that operates on a strings in the document? No, I'm thinking about linking the same nodes in different languages, so that e.g. a cross-reference to a node untranslated in some language can be replaced by a cross-reference to the same node in a different language. Other applications are making statistics about which nodes are translated, or looking for nodes that exist in one lanugage but not other (if you allow translators to write new documentation in their own language). I was merely imagining a human-written (say) German source document; I shouldn't have called it a translation specifically. Support just for that is woefully lacking. I'm not sure what you mean exactly. LilyPond manuals are already partially translated in German; all issues with makeinfo and texinfo.tex I'm aware of have been reported and fixed, I don't see which support for German is lacking. I think European languages already have decent support in Texinfo, even if some improvements would be cool. Let alone (say) Chinese or Arabic, even though all those languages and many more are reasonably well-supported in TeX and in modern systems in general. I haven't tested Texinfo with non-European languages, but issues with documents in Chinese have already been reported on this list. I wouldn't be surprised if a lot of things need to be added or rewritten (even in a rewritten makeinfo :-p) to support non-European languages. This support is a challenge for Texinfo, but I'm not ready to deal with it right now, The challenge I'm trying to take is already big enough. a parser that can be used in these situations, which is far better than using Python regular expressions :-p If you're talking about XML-ish type trees, there is always makeinfo --xml, which is basically an XML representation of the Texinfo source. But you probably already knew that. I knew it exists, but have never investigated so much in this direction for writing my Python scripts. I'm not sure this would be valuable to use for a newly written formatter that takes an XML representation of a Texinfo source as input; this would drastically reduce the cost of rewriting makeinfo, but this involves two parsing stages, and requires external libraries for parsing XML. I'm not familiar with using XML, does have somebody thoughts about this? 1) write a parser Yes. And this alone is a huge job. I'm sure I'm going to have headaches with this, and after this I expect to have fun at writing output backends :-) Heck, just *tokenizing* is not simple. It cannot be done anything like a traditional tokenizer/parser, since the tokens vary in context. For instance, @ is not always an escape (@verbatim ...). I think it might be a good idea to create a Flex rule that catches a whole @ignore or @verbatim block in one go, but this probably involves some trickery in the parser to catch @ignore and @verbatim blocks which don't end properly. And there is no way to parse bigger constructs without actually recognizing/executing some code, because of the verdamnt @macro. This means @macro definitions and calls should be interpreted while parsing, which makes sense. You discouraged me at trying a parser generator, but as you have read above I'm looking at using Flex to generate a lexer. Patrice, Karl, thanks a lot for your hints, unless important ideas are proposed or major issues are raised, I'll start heavily working at writing code next week, and I'd like to make my code publicly available at the end of July, whatever its state -- I'd like to achieve a partial parser, and a minimal text backend that basically ignores all Texinfo commands. Cheers, John
Re: Broken link at http://www.gnu.org/software/texinfo/
On 2008/07/05 18:50 -0500, Karl Berry wrote: Indeed. It is not an easy problem, though. Every space in the input is potentially significant. Macros complicate things enormously. Backward compatibility has to be 100%. The current code fundamentally intermixes reading and writing (it was never designed to output anything but Info), and so is extremely hard to use as a model or even generally comprehend (at least for me). And so on and so forth ... I'm not sure it would be a reasonable effort to make a 100 % backward compatible reimplemention at first go. A more reasonable primary goal is a clean and well-designed implementation that parse without errors almost all existing valid Texinfo documents, and that has only roughly has the behavior as current makeinfo. Only when this is done, it is reasonable to start resolving incompatibilities. I may be wrong, but IMHO it's only possible to tackle the huge task of reimplementing a big program and simultaneously dealing with backward compatibility with a lot of development resources. I made some abortive efforts at starting a rational reimplementation years ago (long-time members of the mailing list may remember previous discussions on the subject) but never got anywhere significant. It seems I'd have to stop everything else I'm doing to have enough time and focus to write such a thing, and I don't see that happening, ever. I'm prepared to stop everything else in a part of my holidays, but not more than two weeks per year :-p I hope I'll have enough view on the long term to be able to make continuous progress. Non-English documents are another huge unsolved problem with the overall Texinfo system. But I digress. That's precisely what motivates a reimplementation of makeinfo : we need a Texinfo parser that builds data trees that represent Texinfo documents, to play with for managing translations. Even if I (or we) fail at writing a fully backward compatible program, we'll have at least a parser that can be used in these situations, which is far better than using Python regular expressions :-p FYI, another contributor sent me a --internal-links option, to dump out index/toc terms as a tsv file. It probably wouldn't be impossible to dump out the node/section tree too. Not that I've looked into it, and since you've already switched it doesn't matter. No, we haven't switched on out Git master branch, but nearly 80 % of the work has been done by Patrice and Reinhold, and this work will probably be useful for a couple of years :-) 3) is precisely what is making us switch to texi2html. Oh? Some people among LilyPond users and contributors want eye-candy, bells and whistles that texi2html can provide with least effort :-p. More seriously, the main motivation to switch to texi2html is that we want to split HTML documentation at arbitrary levels, and at different levels depending on each chapter. That might sound a bit unreasonable at first sight, but so much effort is done on Lily docs these days that we must find a way to organize a growing number of pages of docs -- more than 1100 pages in PDF format currently, including music scores samples. it will take years to achieve if I'm the only (programming amateur) guy on this. Given that I've wanted to rewrite it from scratch for over a decade now, years doesn't sound so bad :). It partly depends on what discipline I'm going to study and work in the coming years: math, or other disciplines including IT. Working on makeinfo will be easier if I study IT of course. I'll know more about this in a few weeks. A call for help has existed for years in various places. The effort required requires so much dedication to get started so random contributors aren't likely to help much, IMHO. The core has to exist, and I think it can only work if it's the vision of a single person, or at most a couple people working very closely. I don't have a precise vision right now, though I've already written paper drafts. Here's a list of possible development stages (that will probably overlap in time): 1) write a parser, which would generate a data tree in Scheme for a Texinfo document -- this stage already involves GUILE interfacing with the main compiled language; 2) write a rough text output backend in the main compiled language -- and maybe an Info backend based on the text backend -- without any possibility of customization at this stage, but keeping in mind customizability will be added later; 3) write some sample scripts showing possible usage of parsed Texinfo source (outputting a tree of nodes, rewriting some tools I wrote in a ugly way in Python for translation 4) Write support for customizing formatting of a backend, and start writing a customizable HTML backend. Of course all this needs to be elaborated and refined as it goes. The main compiled language probably refers to C++: it's the language I know best besides Python, even if I'm far from being a
Re: texinfo.tex: accents in math mode
Karl Berry wrote:
I hoped it would be possible to make texinfo.tex interpret accents as
math accents in math mode
It's hard for me to imagine how to make a pre-accented 8-bit character
into a math accent, though I suppose anything could be done with enough work.
Does it even work that way in LaTeX?
No, the supported command to get \'o in math mode within LaTeX is
\acute{o} (with package amssymb). I've managed to get \'o working in
math mode with the usual set of French packages I use for LaTeX, but
it's a bad solution: the accented character is printed upright instead
of italics, LaTeX complains, and it is no more printed as soon as I
uncomment or change LaTeX packages in the document.
Making something like @^x give you a math accent inside @math and a text
accent outside math seems possible; in fact, my guess (without trying
the experiment) is that it already does.
No, it does not: as I told in my first message (sorry for the possible
mangling with UTF-8 coding), the same error happens if you use something
like @'o inside @math.
I don't know whether the following is an acceptable solution, but
texinfo.tex could maybe turn the @math{@'o} error into a warning, as the
output produced with 'texi2pdf --batch' seems to look good. Anyway, as
we can easily reformulate the piece of LilyPond docs that causes this
error, I don't mind at all if this limitation is not fixed.
Cheers,
John
Re: texinfo.tex: accents in math mode
Oleg Katsitadze wrote:
On Sat, Apr 05, 2008 at 07:14:08PM -0500, Karl Berry wrote:
blablabla @math{\hbox{\it alteracin} 0} blablabla
Does @[EMAIL PROTECTED] 0}} work?
That's the intended usage. (Or maybe some other similar Texinfo cmd.)
@var doesn't work -- it _does_ switch to text italic font, so the
kerning is correct, but text accents are still not allowed (it's still
math mode).
I hoped it would be possible to make texinfo.tex interpret accents as
math accents in math mode, but maybe this is not feasible. So, if I
understand well, it's not possible to avoid @iftex/@ifnottext constructs
in this case.
Thanks for the hints
John
texinfo.tex: accents in math mode
Hi Texinfo hackers,
Spanish translation of LilyPond manual doesn't compile with current
texinfo.tex, although output looks fine. Here's a small example which
reproduces the bug, with the log I get from texi2pdf. A very similar
error message in the log appears when I replace the UTF-8 character 'ó'
with @'o.
Of course, the actual input in LilyPond manual can be reformulated so it
doesn't use @math any more, but fixing this might be more important in
other cases.
\input texinfo
@setfilename mathaccents.info
@settitle Math accents
@documentencoding UTF-8
blablabla @math{alteración 0} blablabla
@bye
$ texi2pdf --batch mathaccents.texi
/usr/bin/texi2dvi: Running pdfetex --file-line-error /dev/null '\nonstopmode'
'\input' './mathaccents.texi' ...
This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
file:line:error style messages enabled.
%-line parsing enabled.
entering extended mode
(./mathaccents.texi (./texinfo.tex Loading texinfo [version 2008-03-31.10]:
pdf, fonts, page headings, tables, conditionals, indexing, sectioning, toc,
environments, defuns, macros, cross references, insertions,
(/usr/local/texlive/2007/texmf-patch/tex/generic/dvips/epsf.tex) localization,
formatting, and turning on texinfo input format.) (./mathaccents.aux)
./mathaccents.texi:6: Please use \mathaccent for accents in math mode.
\'#1-{\accent
19 #1}
argument alteració
n 0
\finishmath #1-#1
$\endgroup
l.6 blablabla @math{alteración 0}
blablabla
[1{/usr/local/texlive/2007/texmf-var/fonts/map/pdftex/updmap/pdftex.map}] )
(see the transcript file for additional information)/usr/local/texlive/2007/te
xmf-dist/fonts/type1/bluesky/cm/cmmi10.pfb/usr/local/texlive/2007/texmf-dist/
fonts/type1/bluesky/cm/cmr10.pfb
Output written on mathaccents.pdf (1 page, 11030 bytes).
Transcript written on mathaccents.log.
/usr/bin/texi2dvi: pdfetex exited with bad status, quitting.
Regards,
John
Re: Failure with texinfo.tex 2008-02-15.11
Karl Berry wrote: Thanks for the report (again), and sorry for the trouble. Please try the texinfo.tex in CVS now ... Thanks, it works! Best, John
Failure with texinfo.tex 2008-02-15.11
Hello,
I have tried to compile LilyPond manuals with latest texinfo.tex from
CVS (2008-02-15.11); pdfetex complained with stopping compilation,
saying 'Undefined control sequence'. I tried to cut the Texinfo sources
down to a minimal example reproducing the problem, with two files
=== test.texi ===
\input texinfo
@setfilename test
@include macros.texi
@internalsref{Foo}
@bye
=
=== macros.texi ===
@macro internalsref{TEXT}
@vindex \TEXT\
@end macro
===
Building with an older texinfo.tex (2007-09-03.05) is successful.
If I replace '@include macros.texi' with the macro definition this file
contains, building is successful with latest texinfo.tex.
The full error log I get is
$ texi2pdf test.texi
/usr/bin/texi2dvi: Running pdfetex --file-line-error './test.texi' ...
This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
file:line:error style messages enabled.
%-line parsing enabled.
entering extended mode
(./test.texi (./texinfo.tex Loading texinfo [version 2008-02-15.11]: pdf,
fonts, page headings, tables, conditionals, indexing, sectioning, toc,
environments, defuns, macros, cross references, insertions,
(/usr/local/texlive/2007/texmf-patch/tex/generic/dvips/epsf.tex) localization,
formatting, and turning on texinfo input format.) (./macros.texi) [1
./test.texi:8: Undefined control sequence.
write \entry{Foo}{\folio }{\code {\xeatspaces
{Foo}\endinput }}
inserted text
}\endwrite
\onepageout ...\ewbot \hfil \ewbot }}\egroup \fi }
}\advancepageno \ifnum \ou...
output {\onepageout {\pagecontents \PAGE }
}
to be read again
\ptexend
l.8 @bye
?
Greetings
John
Re: Strange layout in PDF with quotes
Le samedi 28 juillet 2007 à 18:24 -0500, Karl Berry a écrit : Hi John, @documentencoding UTF-8 as META HTTP-EQUIV=Content-Type CONTENT=text/html; charset=UTF-8 That is what is supposed to happen. And when I run a test document with @documentencoding UTF-8, that's what I get in the --html output, modulo capitalization: $ makeinfo --html -o - utf8.tex ... meta http-equiv=Content-Type content=text/html; charset=utf-8 (With the makeinfo from CVS.) I guess you're not seeing that? How does your document start? Sorry to bother you with this; makeinfo from current CVS is OK, but GUB (Grand Unified Binaries, the home-made build system used to build LilyPond) uses texinfo 4.8. In fact, makeinfo 4.8 is enough for LilyPond, and the sources include a verbatim copy of texinfo.tex (which I regularly update from CVS). Including texinfo.tex in our sources may seem unnecessary or even overkill, but LilyPond has so many dependencies (including CVS snapshots of some packages or patched packages) that we find it a good idea to costless remove one dependency for the user. I played with different makeinfo versions (4.8 and from CVS) and once noticed charset=UTF-8 was missing in HTML output with makeinfo 4.8. As far as I have tested, it seems that adding --enable-encoding flag make all makeinfo versions =4.8 add charset=UTF-8, so you can forget all about this story :-) Sorry again for the noise John
Re: pdfeTeX error when compiling lilypond.texi with accents in node names
Le jeudi 26 juillet 2007 à 20:32 +0300, Oleg Katsitadze a écrit :
On Thu, Jul 26, 2007 at 09:21:04AM +0200, John Mandereau wrote:
A related improvement would be adding a command like
@thinspace to insert a thin unbreakable space.
This should be easy to add. This will make @dmn{} unnecessary, but
whatever. The question is, what should @thinspace produce in HTML and
Info outputs?
As for Info, I guess we can omit the space. This seems ok for
guillemets and abbreviations like `p.123' (page 123). Furthermore,
@dmn{} omits the space, too.
Ommitting a space in Info would be weird for French typography:
@thinspace should be used before an exclamation or question mark and a
right guillemet, and after a left guillemet. When the thin space is
unavailable, a plain or unbreakable space is generally used instead.
As for HTML, there is a hair space (#x200A), but it seems not to be
widely supported by browsers:
http://en.wikipedia.org/wiki/Space_%28punctuation%29#Space_characters_and_digital_typography
So maybe we should omit it in HTML, too.
I don't think so; why not use thinsp;? We already use it in LilyPond
HTML manual. thinsp; is unbreakable in Mozilla Firefox.
Finally, there is a thin space in UNICODE (U+200A). Should we use it
in Info output if encoding is UTF-8?
IMHO yes.
Cheers,
John
Re: Strange layout in PDF with quotes
Le jeudi 05 juillet 2007 à 12:16 -0500, Karl Berry a écrit : By the way, do you use makeinfo with the lilypond manual? Yes, we build the HTML manual in all languages and the Info manual in English. If so, could you see if version in the 4.9.90 pretest (alpha.gnu.org/gnu/texinfo) has any problems? As I now manage to run autogen.sh successfully, I've tested today's CVS Texinfo. The new behaviour of makeinfo regarding UTF-8 encoding is no longer what we expect when building lilypond HTML manual: we expect makeinfo to translate @documentencoding UTF-8 as META HTTP-EQUIV=Content-Type CONTENT=text/html; charset=UTF-8 regardless of makeinfo UTF-8 knoweledge. I agree it is safer not to allow unknown encodings in makeinfo, so if it is a deliberate design decision, we will stick with makeinfo 4.8 to build LilyPond manual. I hope I could help adding real UTF-8 support in makeinfo, but I will have time for this only in Summer 2008. Cheers, John
Re: pdfeTeX error when compiling lilypond.texi with accents in node names
Since there are only a few quotes in section titles in LilyPond manual -- IIRC there is only one title in French with quotes -- support for non-English quotes in normal text will be an important improvement. Sorry for the possible top-posting, but my current email client doesn't allow anything else. Greetings from Auvergne volcanoes John 2007/7/8, Karl Berry [EMAIL PROTECTED]: John, regarding the European quotes: would it be useful to you to have them if they only come out right in the main body text? The quick implementation we can do won't handle them in chapter/section titles, etc. (They'll just come out in text size everywhere.) The right thing will have to wait for the complete font support rewrite, which is still making progress but not yet releasable. Thanks, k
Re: Strange layout in PDF with quotes
Thanks for the fix. Unfortunately, I'm not at home and have no computer access to build LilyPond. I'll be back on July 25th. If testing this bugfix is urgent, I can ask somebody on lilypond-devel to do it. We use makeinfo to build HTML and Info manuals, so I'll test 4.9.90. Cheers, John 2007/7/5, Karl Berry [EMAIL PROTECTED]: much space is often left around the quoted text Thanks for the report, and sorry for the delayed reply. There's a new version at ftp://tug.org/tex/texinfo.tex with the patch below, which fixed it for me. By the way, do you use makeinfo with the lilypond manual? If so, could you see if version in the 4.9.90 pretest (alpha.gnu.org/gnu/texinfo) has any problems? Thanks, karl --- texinfo.tex.~1.248.~2007-07-03 16:10:30.0 -0700 +++ texinfo.tex 2007-07-05 10:09:47.0 -0700 @@ -7506,5 +7506,5 @@ \count255=128 \loop\ifnum\count255256 - \global\catcode\count255=#1 + \global\catcode\count255=#1\relax \advance\count255 by 1 \repeat @@ -7514,5 +7514,5 @@ \count255=128 \loop\ifnum\count255256 - \catcode\count255=#1 + \catcode\count255=#1\relax \advance\count255 by 1 \repeat
Strange layout in PDF with quotes
Dear Texinfo hackers,
We LilyPond translators have found a serious layout problem in LilyPond
PDF manual, with Texinfo 4.9. pdfetex/texinfo.tex seems to be sometimes
confused when formatting text with quotes: much space is often left
around the quoted text, leading to overfull hboxes and a black rectangle
in worst case -- or, if I try to say it differently, line breaks occur
at wrong places.
Fortunately, I could trim down the problem to a small example (see
attached mini_es_sample.texi), taken from LilyPond Spanish manual. If
you uncomment the @ignore'd paragraph, it looks even worse. Log from
texi2pdf is below, and the PDF I get is at
http://john.mandereau.free.fr/mini_es_sample.pdf
FWIW, here are references of the bug in huge LilyPond manuals. Page
numbers indications are physical pages numbers, i.e. those shown by
PDF viewer, not those printed on pages.
http://john.mandereau.free.fr/lilypond-doc/Documentation/user/lilypond.es.pdf
4.1.1 Sugerencias de tipo general, bottom of 54
4.3 Hojas de estilo, 59, 60, 61
http://john.mandereau.free.fr/lilypond-doc/Documentation/user/lilypond.fr.pdf
1.1 Gravure, 13
End of 1.3 Quels signes graver ?, 16
4.1.1 Suggestions g ́en ́erales, bottom of 55
http://john.mandereau.free.fr/lilypond-doc/Documentation/user/lilypond.pdf
4.1.1 General suggestions, bottom of 52
$ texi2pdf mini_es_sample.texi
This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
file:line:error style messages enabled.
%-line parsing enabled.
entering extended mode
(/home/john/bazar/tex/es/mini_es_sample.texi
(/usr/local/texlive/2007/texmf-patch/tex/texinfo/texinfo.tex
Loading texinfo [version 2007-06-29.13]: pdf,
(/usr/local/texlive/2007/texmf-dist/tex/plain/misc/pdfcolor.tex) fonts,
page headings, tables, conditionals, indexing, sectioning, toc,
environments,
defuns, macros, cross references, insertions,
(/usr/local/texlive/2007/texmf-patch/tex/generic/epsf/epsf.tex
This is `epsf.tex' v2.7.3 23 July 2005
) localization, formatting, and turning on texinfo input format.)
(/usr/local/texlive/2007/texmf-patch/tex/texinfo/txi-es.tex)
[EMAIL PROTECTED] 19 @char 16{}}tulo 1
@xrdef{General suggestions-title}{General suggestions}
@xrdef{General suggestions-snt}{Cap@'[EMAIL PROTECTED] [EMAIL PROTECTED] 1}
Overfull \hbox (15.54301pt too wide) in paragraph at lines 18--21
@textrm de los
vi-o-lines,'
`c
uarta|
[1
@xrdef{General suggestions-pg}{1}
{/usr/local/texlive/2007/texmf-var/fonts/map/pdftex/updmap/pdftex.map}] )
(see the transcript file for additional
information)/usr/local/texlive/2007/te
xmf-dist/fonts/type1/bluesky/cm/cmb10.pfb/usr/local/texlive/2007/texmf-dist/f
onts/type1/bluesky/cm/cmbx12.pfb/usr/local/texlive/2007/texmf-dist/fonts/type
1/bluesky/cm/cmr10.pfb
Output written on mini_es_sample.pdf (1 page, 20059 bytes).
Transcript written on mini_es_sample.log.
Cheers,
John
\input texinfo @c -*-texinfo-*-
@documentlanguage es
@documentencoding UTF-8
@macro q{TEXT}
`\TEXT\'
@end macro
@node General suggestions
@chapter General suggestions
@ignore
Presentamos algunas sugerencias que pueden serle de ayuda para evitar
o corregir problemas:
@end ignore
@strong{Comente los archivos}. Utilice o números de compás (de vez en
cuando) o referencias a temas musicales (@q{segundo tema de los
violines,} @q{cuarta variación,} etc.).
@bye
Re: pdfeTeX error when compiling lilypond.texi with accents in node names
Le mercredi 27 juin 2007 à 19:26 -0500, Karl Berry a écrit :
IMHO quotedblbase is a bit more difficult to remember,
I meant those for the German quotes (on the baseline), since those are
the Adobe glyph list name. I'm not sure if baseline quotes are used in
any other language, but it wouldn't surprise me, so I'm a bit doubtful
about making up a new name like gquote.
Agreed. I didn't know Adobe glyph list name. In my command name
proposition, I proposed [lr]gq [lr]gqq with inspiration from LaTeX
german.sty definition, where German quotes are called \g[lr]q \g[lr]qq;
maybe these names could be defined in Texinfo too...
For normal single quotes, maybe we could transform ` in text to lsquo,
but there's no way to disambiguate ', so perhaps we should make up a
command for that.
AFAICS in LilyPond manual, a macro is defined to output lsquo and rsquo
in all output formats, and the following for TeX output works well:
@macro q{TEXT}
`\TEXT\'
@end macro
I don't understand what other glyphs rsquo should be disambiguated with.
I think we may as well support single guillemets (guilsinglleft/right in
the glyph list, just one or ) as well as the regular double
guillemets. Hence my thought of both [lr]guillemet and [lr]guillemets.
At least I think guillemet is the singular word ...
You're right. I don't know when the single (left or right) guillemet
could or should be used, but adding it won't make any harm anyway.
Cheers,
John
Re: pdfeTeX error when compiling lilypond.texi with accents in node names
2007/6/27, Oleg Katsitadze [EMAIL PROTECTED]: On Tue, Jun 26, 2007 at 04:12:55PM -0500, Karl Berry wrote: If it works for John, feel free to commit it and let's give it a try. Ok. John, can you please try the patch and see if the German manual (and others, too) compile without errors? If they do, I'll commit the patch. It works with French, Spanish and German manuals! Thank you very much :-) John
Re: pdfeTeX error when compiling lilypond.texi with accents in node names
Le dimanche 24 juin 2007 à 23:15 +0300, Oleg Katsitadze a écrit :
On Sun, Jun 24, 2007 at 01:18:12AM +0200, John Mandereau wrote:
the crash happened with German manual
I'm glad it worked out for the other languages, but I still don't
understand why should German fail, there shouldn't be any
difference...
Here's attached an almost minimal example showing the problem. If you
replace the umlaut-U with U, texi2pdf successfully compiles it.
In German lilypond.texi, I solved the problem by converting all UTF-8
accents to @- Texinfo accents.
Here's the log I get on my system:
This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
file:line:error style messages enabled.
%-line parsing enabled.
entering extended mode
(/home/john/bazar/tex/uumlaut_macro_bug.texi
(/usr/local/texlive/2007/texmf-patch/tex/texinfo/texinfo.tex
Loading texinfo [version 2007-06-16.10]: pdf,
(/usr/local/texlive/2007/texmf-dist/tex/plain/misc/pdfcolor.tex) fonts,
page headings, tables, conditionals, indexing, sectioning, toc,
environments,
defuns, macros, cross references, insertions,
(/usr/local/texlive/2007/texmf-patch/tex/generic/epsf/epsf.tex
This is `epsf.tex' v2.7.3 23 July 2005
) localization, formatting, and turning on texinfo input format.)
(/usr/local/texlive/2007/texmf-patch/tex/texinfo/txi-de.tex)
[1{/usr/local/texl
ive/2007/texmf-var/fonts/map/pdftex/updmap/pdftex.map}] [2] [-1] Kapitel
1
@xrdef{Bogus-title}{Bogus}
@[EMAIL PROTECTED] 1}
/home/john/bazar/tex/uumlaut_macro_bug.texi:0: Missing number, treated
as zero.
to be read again
{
-{
@tt @char 34}
argument [EMAIL PROTECTED]
7F U}
@sectionheading [EMAIL PROTECTED] [EMAIL PROTECTED] 0 @unhbox 0 #1
[EMAIL PROTECTED] .5 @csname
#2headi...
@genhead ...level @chapterzzz [EMAIL PROTECTED] @seczzz {#3}
@or @numberedsubseczzz
{#3...
l.2 @section [EMAIL PROTECTED] 7F U}
...
l.27 @commonprop
[1
@xrdef{Bogus-pg}{1}
] )
(see the transcript file for additional
information)/usr/local/texlive/2007/te
xmf-dist/fonts/type1/bluesky/cm/cmbx12.pfb/usr/local/texlive/2007/texmf-dist/
fonts/type1/bluesky/cm/cmr10.pfb/usr/local/texlive/2007/texmf-dist/fonts/type
1/bluesky/cm/cmtt12.pfb
Output written on uumlaut_macro_bug.pdf (4 pages, 18697 bytes).
Transcript written on uumlaut_macro_bug.log.
/usr/local/texlive/2007/bin/i386-linux/texi2dvi: pdfetex exited with bad
status, quitting.
/usr/local/texlive/2007/bin/i386-linux/texi2dvi: see
uumlaut_macro_bug.log for errors.
Cheers,
John
\input texinfo @c -*-texinfo-*-
@documentlanguage de
@documentencoding UTF-8
@macro commonprop
@noindent
@section Ü
@end macro
@titlepage
@title Bug report
@page
@end titlepage
@contents
@menu
* Bogus::
@end menu
@node Bogus
@chapter Bogus
@commonprop
@bye
Re: pdfeTeX error when compiling lilypond.texi with accents in node names
Le dimanche 24 juin 2007 à 13:22 -0500, Karl Berry a écrit : Additionnally, I have a related feature request: I'd like to be able to use French and German simple and double quotes in Texinfo TeX output. I guess we could define new commands. What should the commands be named? @[lr]guillemet @[lr]guillemets @[lr]quotebase @[lr]quotedblbase ? IMHO quotedblbase is a bit more difficult to remember, so I prefer the French word guillemet: command UTF-8 char Unicode EC char code @lguillemet «00AB'023 @rguillemet »00BB'024 There are German quotes too -- g stands for German, and I prefer the short names: @lgq or @lgquote ‚ 201A'015 @rgq or @rgquote ‘ 2018'140 @lgqq or @lgdblquote „ 201E'022 @rgqq or @rgdblquote “ 201C'020 There are a lot of issues involved in supporting other fonts, even ones that are as close as EC and CM. This is a long-term project Oleg has made good progress on; hopefully it'll come to fruition later this year. I just thought it would make adding support for French and German quotes easier, but as long as EC can be used only for some particular glyphs, I'm happy enough :-) AFAIK, using EC fonts and T1 font encoding would allow hyphenation of words with accented characters, but it is just luxury now. Thanks for your attention, John
Re: pdfeTeX error when compiling lilypond.texi with accents in node names
Le samedi 23 juin 2007 à 14:36 +0300, Oleg Katsitadze a écrit : On Fri, Jun 22, 2007 at 06:11:44PM -0500, Karl Berry wrote: Oleg, can you see if you can make UTF-8 work in node names per John's sample document? I might be missing something, but I understand that the sample document _does_ work (and it works on my system). It works on my system too. What does _not_ work is the actual manual. No, it doesn't. I'll try to see what's wrong with the manual, but unfortunately Lilypond's build system seems very complex and will take much time for me to just setup. John, maybe you can send me the actual offending .texi file (with all files it depends on), if that is possible, so that I could start from there? Hopefully this will speed up things. The .texi files and all .pdf to be included are 30 MB big. You can download the 13 MB tarball at http://john.mandereau.free.fr/lilypond_texi.tar.bz2 However, if the fix I propose in my reply to Karl works, and if no other major problem (i.e. non-zero texi2pdf exit code) arises, you won't need look at it :-) Besides this, accents disappear in PDF index side pane; is it possible to keep them? That's a much harder problem. I was under the impression that system fonts are used in the bookmark panel, in some unknown encoding. Or is it always UTF-8 these days? Do you know? AFAIK, the text of bookmarks should be either in PDFDocEncoding (a superset of Latin-1) or in Unicode. I'm not sure that either of these are practical to implement from within TeX, at least not in the general case of the document encoding being anything besides Latin-1 or Unicode. PDFLaTeX, which supports the UTF-8 subset equivalent to Latin 1, outputs PDF with bookmarks encoded in Latin 1; the accented characters in these cookmarks look good in Evince on my computer. I don't know how easy it would be to take inspiration from LaTeX UTF-8 support with inputenc and fontenc to improve UTF-8 support in Texinfo/TeX. Regards, John
Re: pdfeTeX error when compiling lilypond.texi with accents in node names
Hi Karl, Karl Berry wrote: That is strange, as the attached sample.texi contains node names and section titles with accents, What's happening is that a UTF-8 e-aigu or whatever is turned into the regular Texinfo equivalent (@'e) in the aux files. This isn't ideal, but was a first step on the road. Not doing that leads to many more complications. If I translate every accented character in lilypond.aux (there are accented characters only in second argument of @xrdef commands) with the following Emacs macro, running again texi2pdf exits successfully (after 2 pdfetex runs) and a good-looking PDF is produced. So, as a quickfix, I propose to add a preprocessing routine in texi2dvi (or a layer in texinfo.tex) that translates UTF-8 accented characters into Texinfo equivalents in @xrdef second arguments (or wherever this is convenient). In the meantime, I'll do this quickfix myself in a preprocessing (sed or whatever) script (I'm not sure I'd be able to implement it in Texinfo itself); this will allow us to know whether there are other major problems with compiling PDF LilyPond manual in French, German and Spanish. I'm not sure how to solve this. If first argument of @xrdef is only used internally, Well, the node name is printed in the output from @xref, etc. Introducing another layer so that the node name is not used directly in control sequence names is possible, but ... is it possible to add a routine which strips accents @-commands in it to avoid the error? In principle, that could lead to clashes, although in practice I suppose it's very unlikely, so it could probably be a first approximation. I naively thought the crash was caused by @xrdef first argument in the .aux file, but as converting accented characters in second argument makes it work, this looks pointless now. Additionnally, I have a related feature request: I'd like to be able to use French and German simple and double quotes in Texinfo TeX output. Why not use European Computer fonts (ec*) as default fonts, instead of Computer Modern? EC fonts provide these quotes whereas AFAIK CM don't. I'm sorry I can't make propositions more to the point, I'm a newbie in plain TeX. John
Re: pdfeTeX error when compiling lilypond.texi with accents in node names
Oleg Katsitadze wrote:
This is so strange that I looked again at you first letter and noticed
something. The log you provided contains:
./lilypond.aux:1: Missing @endcsname inserted.
to be read again
@accent
@'#1-[EMAIL PROTECTED]
19 #1}
argument Pr@'e
face-title
@xrdef #1#2-@expandafter @gdef @csname XR#1
@endcsname
[EMAIL PROTECTED]
@iff...
l.1 @xrdef{Pr@'eface-title}{Préface}
Looking at the definition of @xrdef in the log, I see that it is
different from what texinfo.texi now has. Instead of using #1
directly, it defines and uses @safexrefname which is a sanitized
copy of the original text. Are you absolutely sure you are using the
CVS snapshot of texinfo.texi? Try putting CVS version of texinfo.texi
in the same directory where you build lilypond.texi, and see what
happens.
You mean `texinfo.tex' instead of `texinfo.texi', don't you?
You are right! Compiling French lilypond.texi with texinfo.tex from
recent CVS now works on my computer. I have just noticed LilyPond uses
its own texinfo.tex located in the source tree; it was last merged with
upstream one year ago, so the crash compiling French lilypond.texi is
not surprising. I didn't noticed this stupid problem because I've not
been involved in LilyPond for a long time. After an inspection of
texinfo.tex diff between LilyPond source and Texinfo CVS, I conclude
there is no need to keep a different texinfo.tex any more, so it will
make things a little easier.
pdfetex still crashes if the source isn't converted from utf-8 to
texinfo @-commands (the crash happened with German manual), but this
problem can be worked around with a preprocessing conversion in the
makefile.
There remains only two minor problems: the accents in the bookmarks
panel and support of German and French quotes.
I'm sorry for the noise, and I'm very grateful to your help. I hope I'm
able to contribute anything to improve i18n support in TeXinfo; this
summer, I'll try to look at the TODO and see what I can do.
Many thanks
John
pdfeTeX error when compiling lilypond.texi with accents in node names
{...}' and `\a}' would produce
this error. If you simply proceed now, the `\par' that
I've just inserted will cause me to report a runaway
argument that might be the root of the problem. But if
your `}' was spurious, just type `2' and it will go away.
Runaway argument?
@finish @accent 19 e
./lilypond.aux:1: Paragraph ended before @doiffloat was complete.
to be read again
@par
to be read again
}
argument Pr@'e
face-title
@xrdef ...e [EMAIL PROTECTED] @iffloat @csname XR#1
@endcsname
@expandafter @l...
l.1 @xrdef{Pr@'eface-title}{Préface}
I suspect you've forgotten a `}', causing me to apply this
control sequence to too much text. How can we recover?
My plan is to forget the whole thing and hope for the best.
Greetings
--
John Mandereau [EMAIL PROTECTED]
\input texinfo @c -*-texinfo-*-
@documentlanguage fr
@documentencoding UTF-8
@c
@c %**start of header
@setfilename sample.info
@settitle Test de manuel en français
@c %**end of header
@copying
This is a short example of a complete Texinfo file in French, based on
the sample from GNU Texinfo manual.
@end copying
@titlepage
@title Ceci est un titre avec des caractères accentués
@page
@vskip 0pt plus 1filll
@insertcopying
@end titlepage
@c Output the table of the contents at the beginning.
@contents
@ifnottex
@node Top
@top Échantillon (ou plutôt exemple, mais je voulais des accents) de manuel en français
@insertcopying
@end ifnottex
@menu
* Élucubrations:: chapitre contenant une référence au chapitre suivant
* Référence:: chapitre vide
* Index:: index complet
@end menu
@node Élucubrations
@chapter Élucubrations
@cindex élucubrations
Ceci est le premier chapitre.
@cindex entrée d'index, autre
Voici une énumération.
@enumerate
@item
blablablableûh
@item
blablablablé
@end enumerate
Ceci @ref{Référence} est une référence au chapitre suivant.
@node Référence
@chapter Référence (vide)
Ce chapitre est vraiment vide.
@node Index
@unnumbered Index
@printindex cp
@bye
