The word Über is now found when searching the attached PDF within Evince
on Ubuntu 18.04.5 "Bionic Beaver" using evince 3.28.4-0ubuntu1.2 and
poppler 0.62.0-2ubuntu2.12.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
** Changed in: poppler (Ubuntu)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/116453
Title:
evince can not find ü in attached PDF
(In reply to Jason Crain from comment #14)
> (In reply to Nelson Benitez from comment #13)
> > Hi Jason, thank you very much for the patch, btw, today I was reading this
> > pdf:
> >
> > http://www.compsci.hunter.cuny.edu/~sweiss/course_materials/csci493.70/
> > lecture_notes/GTK_textview.pdf
> >
*** Bug 66569 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/116453
Title:
evince can not find ü in attached PDF
Status in Poppler:
(In reply to Nelson Benitez from comment #13)
Hi Jason, thank you very much for the patch, btw, today I was reading this
pdf:
http://www.compsci.hunter.cuny.edu/~sweiss/course_materials/csci493.70/
lecture_notes/GTK_textview.pdf
and noticed that lot of words with double f, like 'buffer',
Hi Jason, thank you very much for the patch, btw, today I was reading
this pdf:
http://www.compsci.hunter.cuny.edu/~sweiss/course_materials/csci493.70/lecture_notes/GTK_textview.pdf
and noticed that lot of words with double f, like 'buffer', are not
found[1] when searching for it, also when
the fix has been commited upstream, we should get it in next cycle
** Changed in: poppler (Ubuntu)
Status: Triaged = Fix Committed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
Pushed.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/116453
Title:
evince can not find ü in attached PDF
Status in Poppler:
Fix Released
Status in poppler package in Ubuntu:
** Changed in: poppler
Status: Confirmed = Fix Released
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/116453
Title:
evince can not find ü in attached PDF
Status in Poppler:
I think it looks good as it is.
If noone disagrees i'll commit in a week.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/116453
Title:
evince can not find ü in attached PDF
Status
Created attachment 114485
Combine base characters and diacritical marks
My attempt to improve this.
When you make a diacriticized character with LaTeX, ü for example, it
will make a PDF with separate u and ¨ characters and draw them over each
other. This patch detects when this happens and
I certainly remember we already did that combination somewhere, either
in okular or in poppler, but i can't find it and of course the document
does not work, so it may be a fake memory :D
I think this may make sense, though then again preserving the old
behaviour via a flag (even if not default)
Created attachment 113036
[draft] combine characters
I might be able to fix this in a better way by combining letters with
nearby diacritic marks so that this document *would* contain ü. It
seems to be a nice improvement for some latex documents. Attached patch
can give you a rough idea of what
I suppose if I add an option to findText, I should also add a flag
(POPPLER_FIND_IGNORE_COMBINING?) to PopplerFindFlags, for the glib front
end's poppler_page_find_text_with_options(). It would be nice if
someone could confirm that evince would actually use this option.
--
You received this bug
(In reply to Jason Crain from comment #6)
I suppose if I add an option to findText, I should also add a flag
(POPPLER_FIND_IGNORE_COMBINING?) to PopplerFindFlags, for the glib front
end's poppler_page_find_text_with_options(). It would be nice if someone
could confirm that evince would
I understand now. In this case, if über is searched, the reasonable easy
solution is to match uber.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/116453
Title:
evince can not find ü
hdante: the problem is that, despite appearances, the PDF in the bug
description does not contain the word 'Über'. It contains the word
'Uber', without a diaresis. You can see this if you copy and paste from
the document using any PDF reader, including adobe reader, google
chrome, foxit, etc.
I don't really understand what's going on, Unicode has a collation
algorithm, can't it be used ?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/116453
Title:
evince can not find ü in
I'm with Adrian, don't think changing this at such low level is a good
idea.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/116453
Title:
evince can not find ü in attached PDF
Created attachment 112107
Remove combining characters from normalized text
This patch changes normalization so that combining characters are
removed from the normalized text. This makes searching through
TextPage::findText insensitive to these characters.
Also, renames unicodeNormalizeNFKC to
I'm not sure that removing this functionality is a good idea. Can't we
just add an option to findText to enable a looser search and leave it to
the front ends to decide if/how to expose this option.
--
You received this bug notification because you are a member of Desktop
Packages, which is
If you look at the copy and paste from adobe reader and chrome, the word
'Über' is not actually in that document. The diaresis is separate from
the 'U'. We could make search looser by stripping out combining
characters. Looks like that's what adobe reader and chrome do. Is that
the kind of
Jason Crain, thank you for your response.
I appreciate keeping a lean code base to ease maintenance. However, I'm
a strong proponent of functionality compatibility expectations, to ease
the transition for folks from an alternative operating system, and/or
PDF viewer.
Hence, in this select case,
** Summary changed:
- evince can not find special characters in pdfs
+ evince can not find ü in attached PDF
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/116453
Title:
evince can
** Description changed:
Binary package hint: evince
- when using the CTRL+F search function to find a string with special
- characters (e.g. über), evince does not return any matches.
+ 1) lsb_release -rd
+ Description: Ubuntu Vivid Vervet (development branch)
+ Release: 15.04
+
+ 2)
Launchpad has imported 1 comments from the remote bug at
https://bugs.freedesktop.org/show_bug.cgi?id=87215.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
Just found this old bug with status NEW. It works for me with Evince
2.30.3 [poppler/cairo (0.12.4)]. Please reopen this bug if it doesn't
work for you.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
** Changed in: poppler
Status: Confirmed = Invalid
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to poppler in Ubuntu.
https://bugs.launchpad.net/bugs/116453
Title:
evince can not find special characters in pdfs
Status in
28 matches
Mail list logo
