<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Greek support package - some characters output as symbols not letters"
href="https://bugs.freedesktop.org/show_bug.cgi?id=66693#c15">Comment # 15</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Greek support package - some characters output as symbols not letters"
href="https://bugs.freedesktop.org/show_bug.cgi?id=66693">bug 66693</a>
from <span class="vcard"><a class="email" href="mailto:jason@aquaticape.us" title="Jason Crain <jason@aquaticape.us>"> <span class="fn">Jason Crain</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=66693#c12">comment #12</a>)
<span class="quote">> I don't think it makes sense, but even if i did, why would we do
> Πto OE
> but not
> Æ to AE
> ?</span >
Because, for whatever reason, Adobe Reader doesn't touch Æ or æ.
You could also argue that the current pdftotext behavior for these math symbols
is correct because even if Reader changes them into Greek letters, the
characters are actually encoded in the document as math symbols. I'm
ambivalent because I expect someone will complain either way.
<span class="quote">> Would applying the other two patches actually fix this bug? Because you say
> they will fix searching but the bug is about pdftotext</span >
The original description says that search doesn't work because of the
symbol/letter confusion. I assumed Govert meant using the search feature in,
for example, Evince. The way search works, TextPage::findText calls
unicodeNormalizeNFKC and searches through the normalized text. These two
patches cause unicodeNormalizeNFKC to convert the math symbols to letters and
the search matches. This works for Evince, anyway. I haven't tested it with
Okular.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>