On Sun, Mar 18, 2018 at 07:15:11PM +, Bjarni Ingi Gislason wrote:
> On Sun, Mar 04, 2018 at 08:39:44AM +0100, Werner LEMBERG wrote:
>[...]
> The wrong case of hyphenation can easily be corrected by creating a
> file which bans such cases:
>
> a file with lines (or one file for each type)
>> > .ll 1n
>> > .hy 48
>>
>> You *must not* use such values if the patterns don't allow it!
>> From groff.texi:
>>
> I may. That is what testing is about. And I must, otherwise it
> is an insufficient testing.
Well, yes, for testing. And you have to expect incorrect results.
>> instead o
On Sun, Mar 04, 2018 at 08:39:44AM +0100, Werner LEMBERG wrote:
>
> > .ll 1n
> > .hy 48
>
> You *must not* use such values if the patterns don't allow it! From
> groff.texi:
>
I may. That is what testing is about. And I must, otherwise it is an
insufficient testing.
>[...]
>
> instead o
>> As mentioned above, the hyphenation patterns are constructed with
>> certain \lefthyphenmin and \righthyphenmin values. However, those
>> values are *not* present in the hyphenation patterns – you have to
>> know them (I consider this a design bug in TeX). In other words,
>> only the user kno
Hi,
Werner wrote:
> As mentioned above, the hyphenation patterns are constructed with
> certain \lefthyphenmin and \righthyphenmin values. However, those
> values are *not* present in the hyphenation patterns – you have to
> know them (I consider this a design bug in TeX). In other words, only
>
> .ll 1n
> .hy 48
You *must not* use such values if the patterns don't allow it! From
groff.texi:
For historical reasons the default value of the @code{hy} request
doesn't fit the American English hyphenation patterns that are used
by groff as the default. These patterns expect that neit
With
.ll 1n
.hy 48
.hla us
.hpf hyphen.us
.hpfa hyphenex.us
The algorithm
1) uses pattern in the wrong places, at the beginning of a word
although no period is in the pattern
2) splits off one letter at the end although I found no corresponding
pattern in the "hyphen.us" file.
Word
