Re: hyphenation
On Fri, Feb 09, 2018 at 09:06:16PM -0500, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Please insert @hyphenation{auto-ma-ti-cal-ly}
> in texinfo.tex.
OK done.
hyphenation
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
Please insert @hyphenation{auto-ma-ti-cal-ly}
in texinfo.tex.
--
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.
RE: bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation'
Just to clarify that I was suggesting three completely different things: One first thing was better support of internationalization for *Manuals*, in that context I was speaking about node name translation for presentation to user (there should remain a node true name that should remain the same whatever the translation. Ok, sorry if I misunderstood the rationale for the menu entries. One second thing was internationalisation for *DocStrings*, in that context I was suggesting that docstring could contain some link to some manual variable or function description, so switching the Help language based on configured locale would just mean switching to the correct manual translation. BTW, replacing docstring by jump to manual is basically what calc already does, with its h f and h k commands. However it does it in a language dependent way because it does not use the position within the node (call it PWTN) in the command/variable index --- maybe the reason for such an implementation is that when this feature was made available in calc,, info was not supporting so well PWTN --- but instead uses only the node pointer, and then seaches some string in the node to find the position. One third thing is that even plain docstring format itself is language dependant. Only for that third item I was suggesting that a better format for docstrings would be some sort of texinfo-light (I think that texinfmt.el already support some lighter texinfo and could be some starting point for adding such a feature). So in a nutshell the evolved docstring would contain some header indicating - is that legacy format - is that texinfo-light format - do we have a pointer to some manual to be used instead when available and sought for at the configured locale location --- note that the pointer needs only to indentify the manual itself, the variable or function name is already known what you do C-h f or C-h k. Vincent. Date: Mon, 1 Sep 2014 21:53:55 + From: k...@freefriends.org To: vincent@hotmail.fr; 18...@debbugs.gnu.org; bug-texinfo@gnu.org Subject: RE: bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation' use exactly the same node names whatever the language, so that the same link can be used, and when the manual is compiled to multifile HTML, you have the same file tree whatever the language. Seems Currently the usual practice is that a translated document is just another document with some -xx ending in the base name (where xx refers to the language, e.g. fr for French). True. In my opinion an alternative method would be that translated document should rather bare exactly the same name but just be in a language specific directory named xx, with some fall backs to another language No question that that is a well-known alternative approach. * Translated node name: true node name. Some description @node true node name and the viewer is supposed to show only Translated node name. As Gavin says, that is not correct. Both parts of the node name are intended to be shown. The existing use of this feature is to make short menu item abbreviations, e.g., for the sake of completion or just ease of reading. For example, in the Texinfo manual, the HTML Cross References section has a @menu like this: @menu * Link Basics: HTML Xref Link Basics. * Node Expansion: HTML Xref Node Name Expansion. .. Whatever such a hypothetical texinfo-light needs to do, fine. We should think about that separately. It need not affect what Texinfo does. Seems like two very different cases to me. Let's not try to shoehorn existing Texinfo features into things that are far outside their intent and practice. A discussion of such a texinfo-light (not a name I would advocate, either) should presumably take place on emacs-devel, not in a debian bug for Texinfo. k
RE: bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation'
Answers inserted below... Date: Sun, 31 Aug 2014 23:37:06 +0100 Subject: Re: bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation' From: gavinsmith0...@gmail.com To: vincent@hotmail.fr CC: 18...@debbugs.gnu.org; bug-texinfo@gnu.org (adding bug-texinfo) On Fri, Aug 22, 2014 at 11:04 PM, Vincent Belaïche vincent@hotmail.fr wrote: Finally, as an EMACS user, it would be more important to me * if docstring could be written in a sort of texinfo-light format (when you create a package or anything you first do docstring, and then you port this to a manual (so having some texinfo-light format from the beginning would reduce the effort) It might be worth asking on emacs-devel about this to see if anyone wants to implement it or has ideas about how it could work. Concerning the info format, what sort of problem I also see --- still in relation to i18n --- is that one should be able to use exactly the same node names whatever the language, so that the same link can be used, and when the manual is compiled to multifile HTML, you have the same file tree whatever the language. Seems like a good idea to me. Would help for links between manuals and for finding pages in other languages. Are there any guidelines about how to translate Texinfo documents? Currently the usual practice is that a translated document is just another document with some -xx ending in the base name (where xx refers to the language, e.g. fr for French). In my opinion an alternative method would be that translated document should rather bare exactly the same name but just be in a language specific directory named xx, with some fall backs to another language (meaning ../oo, where oo refers to the other language) when manual does not exists. I think that the alternative method is closer to what people usually do for Web sites, in which each language is its own tree replica (file/directory names are same, but only file contents differ). What I am meaning is that using the same node names should not imply that when the final user is reading a manual written in non-English he/she has to see the real node names unless he/she copy to clipboard the node address, one should be able to specify along with the node name a node local name to be presented by the viewer Having translated node names isn't as important because there would be translated headers in the contents of files/nodes saying what section we're in. The main use would be the status bar in a browser giving the current node, and pointers or references to other nodes. I understand it is not ideal to read a cross-reference in another language. Maybe anchors with translated node names could be used instead? That would work for everything (cross-references, pointers) apart from the node name that is displayed in a status bar. Maybe makeinfo would have to be modified to recognize that a menu in a node using anchor names is referring to the child nodes properly. Menus are precisely the only place where you don't need any change in Texinfo, as you can do: * Translated node name: true node name. Some description @node true node name and the viewer is supposed to show only Translated node name. What I was meaning is that the viewer should be configurable to show either the node path with translated names or true names. In the case of nodes that are not referred by any menu, like the top node, or node accessed only by cross reference, there aren't currently any provision in Texinfo to povide a node name translation. That could be some command @localenodename to give that translation inside the node. Vincent.
Re: bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation'
On Mon, Sep 1, 2014 at 8:40 PM, Vincent Belaïche vincent@hotmail.fr wrote: Having translated node names isn't as important because there would be translated headers in the contents of files/nodes saying what section we're in. The main use would be the status bar in a browser giving the current node, and pointers or references to other nodes. I understand it is not ideal to read a cross-reference in another language. Maybe anchors with translated node names could be used instead? That would work for everything (cross-references, pointers) apart from the node name that is displayed in a status bar. Maybe makeinfo would have to be modified to recognize that a menu in a node using anchor names is referring to the child nodes properly. Menus are precisely the only place where you don't need any change in Texinfo, as you can do: * Translated node name: true node name. Some description @node true node name and the viewer is supposed to show only Translated node name. I can imagine cases where a menu label is something other than the node name, for example if the document author wants to give a more extended description of what the node is about. Anyway, names of targets are not usually hidden (in the standalone Info browser, at least). What I was meaning is that the viewer should be configurable to show either the node path with translated names or true names. In the case of nodes that are not referred by any menu, like the top node, or node accessed only by cross reference, there aren't currently any provision in Texinfo to povide a node name translation. That could be some command @localenodename to give that translation inside the node. Something like this could be done by treating an anchor as a synonym for a node if it refers to byte 0 of the node. If someone selected or followed a reference to such an anchor, its name could be displayed instead of the node. There would still be the problem of how makeinfo would do implicit pointer creation with the right node names.
RE: bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation'
use exactly the same node names whatever the language, so that the same link can be used, and when the manual is compiled to multifile HTML, you have the same file tree whatever the language. Seems Currently the usual practice is that a translated document is just another document with some -xx ending in the base name (where xx refers to the language, e.g. fr for French). True. In my opinion an alternative method would be that translated document should rather bare exactly the same name but just be in a language specific directory named xx, with some fall backs to another language No question that that is a well-known alternative approach. * Translated node name: true node name. Some description @node true node name and the viewer is supposed to show only Translated node name. As Gavin says, that is not correct. Both parts of the node name are intended to be shown. The existing use of this feature is to make short menu item abbreviations, e.g., for the sake of completion or just ease of reading. For example, in the Texinfo manual, the HTML Cross References section has a @menu like this: @menu * Link Basics: HTML Xref Link Basics. * Node Expansion:HTML Xref Node Name Expansion. .. Whatever such a hypothetical texinfo-light needs to do, fine. We should think about that separately. It need not affect what Texinfo does. Seems like two very different cases to me. Let's not try to shoehorn existing Texinfo features into things that are far outside their intent and practice. A discussion of such a texinfo-light (not a name I would advocate, either) should presumably take place on emacs-devel, not in a debian bug for Texinfo. k
Re: bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation'
(adding bug-texinfo) On Fri, Aug 22, 2014 at 11:04 PM, Vincent Belaïche vincent@hotmail.fr wrote: Finally, as an EMACS user, it would be more important to me * if docstring could be written in a sort of texinfo-light format (when you create a package or anything you first do docstring, and then you port this to a manual (so having some texinfo-light format from the beginning would reduce the effort) It might be worth asking on emacs-devel about this to see if anyone wants to implement it or has ideas about how it could work. Concerning the info format, what sort of problem I also see --- still in relation to i18n --- is that one should be able to use exactly the same node names whatever the language, so that the same link can be used, and when the manual is compiled to multifile HTML, you have the same file tree whatever the language. Seems like a good idea to me. Would help for links between manuals and for finding pages in other languages. Are there any guidelines about how to translate Texinfo documents? What I am meaning is that using the same node names should not imply that when the final user is reading a manual written in non-English he/she has to see the real node names unless he/she copy to clipboard the node address, one should be able to specify along with the node name a node local name to be presented by the viewer Having translated node names isn't as important because there would be translated headers in the contents of files/nodes saying what section we're in. The main use would be the status bar in a browser giving the current node, and pointers or references to other nodes. I understand it is not ideal to read a cross-reference in another language. Maybe anchors with translated node names could be used instead? That would work for everything (cross-references, pointers) apart from the node name that is displayed in a status bar. Maybe makeinfo would have to be modified to recognize that a menu in a node using anchor names is referring to the child nodes properly.
Re: bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation'
From: Vincent Belaïche vincent@hotmail.fr Cc: 18...@debbugs.gnu.org, Texinfo bug-texinfo@gnu.org Date: Fri, 22 Aug 2014 15:01:43 +0200 - texi2any must collapse multiple blanks in node names *everywhere*, but it is still allowed to break and indent a node name containing a blank accross a line in the case of a note. - info viewer must handle node name split accross lines, but it does not need to make multiblank reduction in other-cases Now, if the above is agreable, then in the case of our problem this would imply that when texi2any meets that kind of menu entry * NODENAME:: SOME TITLE It must convert it to within the info file: * NODENAME: NODE NAME. SOME TITLE Or it should remove the extra blanks, i.e. produce this: * NODE NAME:: SOME TITLE Or it could emit a warning, or even error out. IOW, I see no reason to silently tolerate such cases. They are surely unintended. Eli: 1) do you agree on my re-caping and suggestion ? Almost, see above. 2) do you think that all the same, robustifying the info viewer in the case of menu entry has some benefit --- after all this allows: 2.1) to cope with job done by earlier versions of makeinfo in this corner case 2.2) to have very slightly smaller info file still in this corner case I'm on the fence about this.
RE: bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation'
Hello Eli, Gavin, Patice, Karl. Looping also through Patrice Dumas and Karl Berry and texinfo-bug list. Useful links: http://savannah.gnu.org/bugs/?43045 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18308 Answers comments below: Date: Fri, 22 Aug 2014 09:36:14 +0300 From: e...@gnu.org Subject: Re: bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation' To: vincent@hotmail.fr CC: gavinsmith0...@gmail.com; 18...@debbugs.gnu.org [...] I a nutshell, there are cases of node references where the info viewer is not bothered by internal multiple spaces (this cross reference inside bash manual), and other cases where the info viewer cannot handle it (the case of node (texinfo) @- @hyphenation pointer in menu entry of upper node). Emacs already does all that, of course. Just not in the case of the menu entries, where the node names are not expected to span more than one line. I have checked that in the case of the node line: File: texinfo.info Node:node name ... the texi2any compiler does correctly the multiblank collapsing. Basically, trying to recap, if I get it, the work split that you (Eli) are suggesting between info viewer and texi2any compiler is as follows: - texi2any must collapse multiple blanks in node names *everywhere*, but it is still allowed to break and indent a node name containing a blank accross a line in the case of a note. - info viewer must handle node name split accross lines, but it does not need to make multiblank reduction in other-cases Now, if the above is agreable, then in the case of our problem this would imply that when texi2any meets that kind of menu entry * NODENAME:: SOME TITLE It must convert it to within the info file: * NODENAME: NODE NAME. SOME TITLE Eli: 1) do you agree on my re-caping and suggestion ? 2) do you think that all the same, robustifying the info viewer in the case of menu entry has some benefit --- after all this allows: 2.1) to cope with job done by earlier versions of makeinfo in this corner case 2.2) to have very slightly smaller info file still in this corner case Gavin Patrice, do you agree on my suggestion how to evolve texi2any and stand-alone info viewer ? So, on second thoughts, I am thinking in the end that for consistency, the info viewer not only should, but also _must_ be corrected. As I said, maybe. But the fact is that the _Texinfo_source_ of the Texinfo manual uses different amounts of blanks in this node's name. So line breaking and filling in the Info file is not the issue here. I am even speculating that in the case of the manual menu entry, probably it was intentional to put more spaces for the entry to read better (as @- and @hyphenation are two different commands, isn't it a good idea to put a little more space between them). The problem is _inconsistency_, not extra blanks. The number of blanks should have been consistent in all the uses of this node name. I think that the root of that _inconsistency_ problem is that when you write the following: * NODENAME:: SOME TITLE NODENAME has two meanings: 1) it is the menu label, ie what the user will see, so you are not allowed to collapse blanks, because this would change what the author want to be diplayed to the user 2) it is also the node pointer, so in this case you have to collapse blanks. Karl: don't you think that *ALSO* the manuel should be changed to be written as * NODENAME: NODE NAME. SOME TITLE In the case of info node `(texinfo) @- @hyphenation'. Maybe it is not such a good practice to write it the other way round, because if the author has some intention to display things in some specific way, then for maintainability that should be explicit in the way as it is written in the texinfo code. Vincent.
Re: texinfo.tex: hyphenation not working
How to enable hyphenation of this word? The hyphenation points are already being considered. I put @loggingall in the source and inspected the resulting paragraph breaking; it has the expected discretionaries for the determining. What's happening is that TeX is trying to minimize badness over the entire paragraph, by making the interword spaces as equal as possible. In this case, the whole thing has to be set far too loosely, due to the vast unbreakable url. So the interword space huge. So the intersentence space after Word_Boundaries., which is 3x the interword space, becomes truly enormous. The last line has normal interword spacing because the hfil glue at the end of the paragraph overwhelms the stretchability between words. I don't see how anything can make this paragraph look decent except either allowing line breaks within the url or rewriting. Just a few more words before the url and it comes out ok. karl
texinfo.tex: hyphenation not working
Hi Karl,
I'm using texinfo.tex from texinfo-4.13 (labeled version 2008-04-18.10).
In my .texi source file I have this paragraph:
This is a more low-level API. The word break property is a property defined
in Unicode Standard Annex #29, section ``Word Boundaries'', see
@url{http://www.unicode.org/reports/tr29/#Word_Boundaries}. It is used
for determining the word breaks in a string.
The output from texi2dvi (save in .pdf) is as attached. You can see too much
white space in the third line. It looks like hyphenating the word determining
could solve the issue. But it does not work. After I change the paragraph to
This is a more low-level API. The word break property is a property defined
in Unicode Standard Annex #29, section ``Word Boundaries'', see
@url{http://www.unicode.org/reports/tr29/#Word_Boundaries}. It is used
for d...@-ter@-...@-ning the word breaks in a string.
no hyphenation occurs. The output is still the same.
How to enable hyphenation of this word?
Bruno
inline: ugly-paragraph.png
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: texinfo 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. Yes, some strings got translated, but there wasn't any hyphenation support. 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). Yes, probably. 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. They are essential; without the new versions the right hyphenation patterns aren't selected. Werner
Re: texinfo supports non-English hyphenation
it already partially It used English hyphenation patterns in all cases (and still does, if the real patterns aren't there). I didn't notice any hyphenation difference after updating texinfo.tex, but I guess TeXlive 2008 is needed to see improvements More precisely, what you need (besides texinfo.tex and txi-LL.tex) is an etex (or pdftex) .fmt that includes the patterns. And indeed, this is the case by default in TL08 and was not the case by default in TL07. Although in principle you could change things around in TL07, I suspect it would be far less work for everyone to simply install TL08 if you want the new hyphenation. (The native install won't interfere with your system installation.) karl
Re: hyphenation in non-English languages
It works with etex too if you use I made changes to texinfo.tex and all the txi-??.tex files to implement this. Thanks very much for the suggestion and code. karl
Re: hyphenation in non-English languages
Do you want to? Will have a look, but I can't promise anything due to time constraints. To get some basic non-English hyphenation support, almost nothing has to be changed if you use the current TeXLive. Here I demonstrate what to do for German. . The basic trick is to process the texinfo file with `eplain' instead of `tex'. With TeXLive, this gives access to all configured hyphenation patterns. `bplain' would do the same, but there is (currently) no soft link to the `tex' binary. . In txi-de.tex, add the following lines at the very beginning: \makeatletter \global\lefthyphenmin 2 \global\righthyphenmin 2 [EMAIL PROTECTED] \makeatother That's it. Add, for example, the following at the beginning of your texinfo file: @documentlanguage de @documentencoding UTF-8 Other languages can be handled similarly. You can use any input encoding -- since texinfo has hardcoded support for CM fonts only, words with accented letters aren't hyphenated anyway. A minor problem is that there is no `pdfeplain' command in TeXLive yet, but this is very easy to fix. How shall we proceed? Werner
Re: hyphenation in non-English languages
Hi Werner, On Do, 02 Okt 2008, Werner LEMBERG wrote: . The basic trick is to process the texinfo file with `eplain' instead of `tex'. With TeXLive, this gives access to all configured hyphenation patterns. `bplain' would do the same, but there is (currently) no soft link to the `tex' binary. What is bplain, we can add it ... Other languages can be handled similarly. You can use any input encoding -- since texinfo has hardcoded support for CM fonts only, words with accented letters aren't hyphenated anyway. Hmm, that is not the best option. Any way around that? A minor problem is that there is no `pdfeplain' command in TeXLive yet, but this is very easy to fix. That is the easiest thing to fix. Karl will answer. Best wishes Norbert --- Dr. Norbert Preining [EMAIL PROTECTED]Vienna University of Technology Debian Developer [EMAIL PROTECTED] Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- What was the self-sacrifice? I jettisoned half of a much loved and I think irreplaceable pair of shoes. Why was that self-sacrifice? Because they were mine! said Ford crossly. I think we have different value systems. Well mine's better. That's according to your... oh never mind. --- Douglas Adams, The Hitchhikers Guide to the Galaxy
Re: hyphenation in non-English languages
(I think this has nothing to do with Texinfo, but for TeX Live purposes ...) `bplain' would do the same, but there is (currently) no soft link to the `tex' binary. (Norbert, bplain = babel plain) Would it useful to have? Although there is a bplain.ini file, I see no sign that there was ever a bplain executable. Not sure it would mean much to add it now, since evidently no one is using it.
Re: hyphenation in non-English languages
. The basic trick is to process the texinfo file with `eplain'
Wouldn't it work with etex? I don't see that any eplain-specific
features are being used. (\makeat*er being trivial, as we all know.)
texi2dvi already uses etex (or pdf[e]tex) when they are present. So in
this case, I don't think there is anything special to do. Which is
excellent news :).
. In txi-de.tex, add the following lines at the very beginning:
Very nice! It did not occur to me that we could make use of txi-de.tex,
but it makes sense. I can work on this.
Is there a simple table somewhere of the correct \{left,right}hyphenmin
values? I don't relish digging into all the babel files.
since texinfo has hardcoded support for CM fonts only,
words with accented letters aren't hyphenated anyway.
FYI, Oleg has been working on real support for other encodings and other
fonts for some time. As you can imagine, it is highly nontrivial.
Thanks much,
karl
Re: hyphenation in non-English languages
. The basic trick is to process the texinfo file with `eplain'
Wouldn't it work with etex?
No. As outlined in babel.pdf, plain.tex must not be modified, thus
there are only US-English hyphenation patterns available.
Is there a simple table somewhere of the correct
\{left,right}hyphenmin values? I don't relish digging into all the
babel files.
I'm not aware of such a list.
FYI, Oleg has been working on real support for other encodings and other
fonts for some time.
I know.
As you can imagine, it is highly nontrivial.
But as soon as such a code is there, it shouldn't be cause much
problems to adapt it for hyphenation patterns also.
Werner
Re: hyphenation in non-English languages
On Do, 02 Okt 2008, Karl Berry wrote:
Is there a simple table somewhere of the correct \{left,right}hyphenmin
values? I don't relish digging into all the babel files.
grep lefthyphenmin Master/tlpkg/tlpsrc/*
??
We added all that is known there for exactely that purpose. In fact it
is generated from the hyph-utf8 package, and Mojca/Arthur have collected
that.
Best wishes
Norbert
---
Dr. Norbert Preining [EMAIL PROTECTED]Vienna University of Technology
Debian Developer [EMAIL PROTECTED] Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
---
MALIBU (n.)
The height by which the top of a wave exceeds the height to which you
have rolled up your trousers.
--- Douglas Adams, The Meaning of Liff
Re: hyphenation in non-English languages
No. As outlined in babel.pdf, plain.tex must not be modified, thus there are only US-English hyphenation patterns available. Not so. etex loads all the patterns (and plain.tex remains unmodified, of course). This was a change in 2008, although it could have been done earlier. It is tex which only has Knuth's US ENglish. karl
Re: hyphenation in non-English languages
Wouldn't it work with etex? No. As outlined in babel.pdf, plain.tex must not be modified, thus there are only US-English hyphenation patterns available. Sorry, my mistake. It works with etex too if you use this snippet instead of the previous one: [EMAIL PROTECTED] \global\lefthyphenmin 2 \global\righthyphenmin 2 [EMAIL PROTECTED] [EMAIL PROTECTED] So the fix to get some basic hyphenation is really trivial. Werner
Re: hyphenation in non-English languages
any chance that this gets implemented on the TeX side? It would be very nice. Basically, it should be just an interface to the plain TeX implementation of Babel, right? I don't know. All we really have to do is set \language. Do we need Babel for that? Now that etex (in TL'08) is dumped with all available languages, it seems like it should be plausible. The necessity of dumping a format had been mentally blocking me. Has someone worked on this already? No. Do you want to? Thanks, Karl
Re: hyphenation in non-English languages
Basically, it should be just an interface to the plain TeX implementation of Babel, right? I don't know. All we really have to do is set \language. Do we need Babel for that? Well \language expects a number, doesn't it? Using Babel, we can use a string instead... Has someone worked on this already? No. Do you want to? Will have a look, but I can't promise anything due to time constraints. Werner
Re: hyphenation in non-English languages
Well \language expects a number, doesn't it? Yes. Using Babel, we can use a string instead... Clearly we have to map from the existing @documentlanguage strings in Texinfo to the numbers that were dumped in the .fmt file for the various languages. If Babel can help us do that, and not induce new compatibility problems along the way, fine. Or if we write some homegrown mapping, also fine. I have never actually looked into how we can get the language names back out. karl
hyphenation in non-English languages
Folks, any chance that this gets implemented on the TeX side? Basically, it should be just an interface to the plain TeX implementation of Babel, right? Has someone worked on this already? Werner
