kludge@panix.com (Scott Dorsey) writes:

> You also would see a lot of weird ligatures back then which are seldom
> seen today. Some of that stuff didn't actually disappear until automated
> typesetting came along, as there are only so many keys on the linotype.

I'm seeing instances of ligature in on-line docs, ff, fi, ffi, fl, ffl
and even st. (I understand the reasoning behind the existence of the
f-ligatures but not st, less so why it would be used in an electronic
doc.)

This actually turns out to be an embuggerance. The most recent
version of xpdf (PDF reader for Linux) I have, when given a text
search request for "Kauffmann" will fail to return any instances. But
(knowing that Kauffmann was an important relevant author) a quick look
at the bibliography revealed multiple instances among other found on
reading full text.

The PDF author had used used the ff ligature from whatever
$CURRENTLY-KEWL-CHARSET which was rendered readably. But the xpdf
author wasn't clueful enough to realize that no user ever enters a
ligature character code from the keyboard as a search target and write
compensating translations into the source code.

--
Mike Spencer Nova Scotia, Canada

In comp.misc Mike Spencer <mds@bogus.nodomain.nowhere> wrote:
>
> kludge@panix.com (Scott Dorsey) writes:
>
>> You also would see a lot of weird ligatures back then which are seldom
>> seen today. Some of that stuff didn't actually disappear until automated
>> typesetting came along, as there are only so many keys on the linotype.
>
> ...
>
> The PDF author had used used the ff ligature from whatever
> $CURRENTLY-KEWL-CHARSET which was rendered readably. But the xpdf
> author wasn't clueful enough to realize that no user ever enters a
> ligature character code from the keyboard as a search target and write
> compensating translations into the source code.

It may not be xpdf's author's fault. If the pdf creator did not
provide a proper reverse map table from the code point used for the ff
ligature to its actual character (or characters) then there's nothing a
pdf reader can do to fix the problem.

The problem is that the PDF specification allows for the PDF creator to
create arbitrary mappings from byte values used in the PDF file to any
given glyph in a font file. But it makes optional the reverse mapping
table which would define to a PDF reader program that "byte value 0x32
in this portion of this PDF [1] represents the 'ff' litgature".
Without that reverse table, PDF is effectively a "write only medium".
It will print a perfect document, but you can't search, nor copy out,
anything from it.

[1] 0x32 can be made to represent any number of different glyphs within
a single given PDF. In fact, if one were so devious as to do so, every
byte in the pdf representing a text character could be 0x32, and each
one could "print" to the electronic sheet of paper a different font
glyph.

Rich <rich@example.invalid> writes:

> In comp.misc Mike Spencer <mds@bogus.nodomain.nowhere> wrote:
>>
>> The PDF author had used used the ff ligature from whatever
>> $CURRENTLY-KEWL-CHARSET which was rendered readably. But the xpdf
>> author wasn't clueful enough to realize that no user ever enters a
>> ligature character code from the keyboard as a search target and write
>> compensating translations into the source code.
>
> It may not be xpdf's author's fault. If the pdf creator did not
> provide a proper reverse map table from the code point used for the ff
> ligature to its actual character (or characters) then there's nothing a
> pdf reader can do to fix the problem.
>
> The problem is that the PDF specification allows for the PDF creator to
> create arbitrary mappings from byte values used in the PDF file to any
> given glyph in a font file. But it makes optional the reverse mapping
> table which would define to a PDF reader program that "byte value 0x32
> in this portion of this PDF [1] represents the 'ff' litgature".
> Without that reverse table, PDF is effectively a "write only medium".
> It will print a perfect document, but you can't search, nor copy out,
> anything from it.

Thank you for that. Groveling through the PDF spec is well above my
pay grade. It sounds like a can of worms to me -- creeping
featuritis, make any weird hack the devs can think of possible.

Huh. Tnx.

> [1] 0x32 can be made to represent any number of different glyphs within
> a single given PDF. In fact, if one were so devious as to do so, every
> byte in the pdf representing a text character could be 0x32, and each
> one could "print" to the electronic sheet of paper a different font
> glyph.

--
Mike Spencer Nova Scotia, Canada

On 30 Mar 2024 18:36:47 -0300, Mike Spencer
<mds@bogus.nodomain.nowhere> wrote:

> I understand the reasoning behind the existence of the
> f-ligatures but not st, less so why it would be used in
> an electronic doc.

Wild guess: if there are also 'nd', 'rd' and 'th' ligatures, it
is probably meant for constructs like
1st, 2nd, 3rd, 4th, ... etc.

Also, some of the ligatures could be used for "kerning".

<https://en.wikipedia.org/wiki/Ligature_(writing)>
<https://en.wikipedia.org/wiki/Kerning>

--
Kees Nuyt

Kees Nuyt <k.nuyt@nospam.demon.nl> wrote:
>On 30 Mar 2024 18:36:47 -0300, Mike Spencer
><mds@bogus.nodomain.nowhere> wrote:
>
>> I understand the reasoning behind the existence of the
>> f-ligatures but not st, less so why it would be used in
>> an electronic doc.
>
>Wild guess: if there are also 'nd', 'rd' and 'th' ligatures, it
>is probably meant for constructs like
>1st, 2nd, 3rd, 4th, ... etc.
>
>Also, some of the ligatures could be used for "kerning".
>
><https://en.wikipedia.org/wiki/Ligature_(writing)>
><https://en.wikipedia.org/wiki/Kerning>

On the linotype kerning isn't handled by a separate type mold like
ligatures are, but there is a lever that you pull to enable it to
squish molds together. I don't know how it works inside the mechanism.

With handset type it varies depending on the font.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

In comp.misc Kees Nuyt <k.nuyt@nospam.demon.nl> wrote:
> On 30 Mar 2024 18:36:47 -0300, Mike Spencer
> <mds@bogus.nodomain.nowhere> wrote:
>
>> I understand the reasoning behind the existence of the
>> f-ligatures but not st, less so why it would be used in
>> an electronic doc.
>
> Wild guess: if there are also 'nd', 'rd' and 'th' ligatures, it
> is probably meant for constructs like
> 1st, 2nd, 3rd, 4th, ... etc.
>
> Also, some of the ligatures could be used for "kerning".
>
> <https://en.wikipedia.org/wiki/Ligature_(writing)>
> <https://en.wikipedia.org/wiki/Kerning>

Possibly, but one can perform kerning without resorting to using
ligatures. The ligatures appear to be a holdover from when documents
were handwritten (often with a fountain pen) and the ligatures were
just a direct result of how the pen lays down the ink (and the writer
not lifting the pen sufficiently to avoid laying down ink).