Cyrillic not displayed in the input field

Bug #1288182 reported by lioncub on 2014-03-05
256
This bug affects 57 people
Affects Status Importance Assigned to Milestone
Evince
Unknown
High
Poppler
New
Unknown
evince (Ubuntu)
High
Unassigned
poppler (Ubuntu)
High
Unassigned

Bug Description

Ubuntu 14.04 x64
Evince 3.10.3
Cyrillic not displayed in the input field.

In attach screenshot: input field with text 'This сyrillic: "Кириллица"'

Upd.

Still actual for Ubuntu 16.04 x64
Evince 3.18.2

messages in console:

Japanese (日本国):
warning: layoutText: cannot convert U+65E5
warning: layoutText: cannot convert U+672C
warning: layoutText: cannot convert U+56FD

Cyrillic (привет):
warning: layoutText: cannot convert U+043F
warning: layoutText: cannot convert U+0440
warning: layoutText: cannot convert U+0438
warning: layoutText: cannot convert U+0432
warning: layoutText: cannot convert U+0435
warning: layoutText: cannot convert U+0442

Hi Stanislav,

can you please attach a document showing the issue?

Created attachment 19393
Test forms with Kanji and Cyrillic

Reading comments from http://qa.openoffice.org/issues/show_bug.cgi?id=42985 it looks like the issue is that embedded font does not have unicode characters. Are there any news about this bug?

Created attachment 38442
screenshot of font property of sample PDF 19393

The sample PDF has no embedded fonts, and the referred font
is Helvetica under WinAnsiEncoding only. So giving Unicode
text for Japanese & Cyrillic codepoint is wrong. When it is
opened by Adobe Reader, strangely, the font tab in property
window shows KozMinPr6N-Regular (Adobe Reader's default font for
Adobe-Japan1) as if it's subsetted & embedded. If I hide
KozMinPr6N-Regular.otf from Adobe Reader, then AdobeMingStd-Light
(Adobe Reader's default font for Adobe-CNS1) is shown as if
it is subsetted & embedded. If I hide it, AdobeSongStd-Light
(for Adobe-GB1) is shown as if ...

I'm afraid that Adobe Reader shows Kanji & Cyrillic text by
some fallback feature, and poppler's behaviour is not a bug,
although it is not inconvenient than Adobe Reader.

Sorry for typo.
I meant "although it is inconvenient than Adobe Reader"

I confirm this bug (or missing feature).

It not only affects Arabic or Hebrew characters! I tried to insert a "line
separator" (Unicode character '\u2028') into a text field of a PDF form. In
Gnome (e.g. in a Terminal) this works by pressing Ctrl+Shift+u 2 0 2 8. In
acroread it works similar (just keep pressing Ctrl+Shift while typing the
digits). Evince displays a PDF form with '\u2028' as expected. But a '\u2028'
cannot be inserted and is even removed whenever the containing text field is
edited somehow!

For details about why and how PDF forms may contain '\u2028' or '\u2029' see
http://blogs.adobe.com/formfeed/2009/01/paragraph_breaks_in_plain_text.html

( This is a copy of my comment https://bugzilla.gnome.org/show_bug.cgi?id=627024#c4 )

lioncub (lioncub) wrote :
lioncub (lioncub) wrote :

In Attachment archive screen.7z:
sample.pdf - sample pdf with form
about.png - about Evince
write.png - write word "Кириллица" in input field
show.png - when they lose focus or change the input field

Word "Кириллица" is not visible

Alex_ander (ks-alexandr) wrote :

confirm this bug, Ubuntu 14.04 (Unity) x32 with the latest updates.

Sebastien Bacher (seb128) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

Changed in evince (Ubuntu):
importance: Undecided → High
Sebastien Bacher (seb128) wrote :

thanks

Changed in evince (Ubuntu):
status: New → Triaged
Changed in evince:
importance: Unknown → High
status: Unknown → New
IV (djashlar) wrote :

Confirm this bug, Ubuntu 14.04 (Unity) x64 with the latest updates. Forward solutions.

gmx (g-gmx) wrote :

Confirm this bug, Ubuntu 14.04 (Unity) x32 the latest updates. Really looking forward to solve the problem.

Tamir (sugip) wrote :

Confirm this bug, Ubuntu 14.04 (xfce) x32 the latest updates. Really looking forward to solve the problem.

Confirms bug Evince 3.10.3 (uses poppler / cairo (0.24.1). Really looking forward to solve the problem

Den (denis-rackitniy) wrote :

Confirm this bug Evince 3.10.3 , Ubuntu 14.04 (xfce) x64

Confirms bug Evince 3.10.3 x64

Alex (alex-serpuxov) wrote :

Confirm this bug, Ubuntu 13.10 x86 (xfce)

Confirms bug.
Any progress?

Sebastien Bacher (seb128) wrote :

Thanks, there is no need of extra confirmations though ;-)

Changed in evince:
status: New → Unknown

I confirm this bug.

Confirms bug, looking forward to solve the problem.

Confirms bug Evince 3.10.3, Okular 0.18

Confirms bug Evince 3.10.3, Okular 0.18 (uses poppler)

Confirm this bug.

Stop saying "confirm this bug". Do you think it helps? No it does not.

Then please enlighten that you need to solve this bug?

A patch that fixes it would be nice. If you can't provide that infinite amounts of time would be nice too. If you can't provide that maybe you can hire someone to code the patch for you.

Okay, I will do my best

confirm this bug - trying in the evince, okular - the best readers in the Linux :(

Changed in evince (Ubuntu):
status: Triaged → Invalid
Changed in poppler (Ubuntu):
status: New → Triaged
importance: Undecided → High
Changed in poppler:
importance: Unknown → Medium
status: Unknown → Confirmed
Changed in poppler (Ubuntu):
status: Triaged → New
status: New → Invalid
Tamir (sugip) on 2014-04-18
Changed in evince (Ubuntu):
status: Invalid → Confirmed
status: Confirmed → Invalid
Changed in evince (Ubuntu):
status: Invalid → Triaged

It don't show cyrrilic comments in Ocular.

noizo (noizo) wrote :

its 7 years from bug has appeared, any solution?

madbiologist (me-again) on 2015-09-21
tags: added: trusty
madbiologist (me-again) wrote :

This bug exists in a slightly altered form on Ubuntu 15.04 "Vivid Vervet". Fields containing Cyrillic text now remain filled when navigating to another field, but the text is corrupted - see attached screenshot. This corrupted text also shows in Print Preview.

tags: added: vivid
Simplehuman (simplehuman) wrote :

Actualizing description, adding tags for new affected Ubuntu versions.

tags: added: wily xenial
description: updated

Sill actual for Evince 3.18.2

I confirm this bug.

Compiled the latest poppler trunk from the GIT repository - 0.40.0 including commits up to commit ab3c9ccb630004be049cb59f303612aa2a35f408 - on Ubuntu 16.04 daily with updates. Also compiled the latest trunk of qpdfview - 0.4.16.99 - including all the funny libraries and passing all tests.

No improvement.

Solution:
Install the latest Windows 10 (64bit) version of Foxit Reader using wine (staging or devel from wine PPA on Ubuntu) and open the file in it. Works like a charm, looks beautifully.

Alternative solution:
Is there any alternative to poppler on Linux? Note that Foxit for Linux 1.0.1.0925 does not even support forms! You can add text via comments, but then again, the "special" characters are broken or invisible (amusingly in a different way than using poppler).

Affected readers (confirmed):
evince (called Document viewer on Ubuntu), okular, qpdfview, Foxit Reader for Linux

Not affected:
Foxit Reader for Windows on wine-1.9.3 (Staging))

Not working (crashes on wine-1.9.3 (Staging)):
Adobe acrobat reader XI for Windows on Wine

To demonstrate the problem, type this into a PDF form:
Příliš žľuťoučký kůň úpěl ďábelské ódy

Some character disappear, some are replaced with free spaces and become invisible. If entered using Foxit Reader for Windows however, the whole phrase displays correctly on Linux PDF viewers. It becomes malformed when copied into any other form.

suslikk (suslikkreal) wrote :

Confirm bug on Ubuntu 16.04...

Artem (sherba800) wrote :

Tooo tired of this bug. Sometimes i need to fill some forms in Russian but Evince still doesn't provide this feature working properly. Do something please!

So 8 years passed and no fix for this?

Anton Khabarov (2233009-f) wrote :

confirm this bug, Ubuntu 14.04 x64 with the latest updates. Evince 3.10.3

I tested with this form: http://archive.mid.ru//bul_ns_en.nsf/uvedomlenie.pdf

Foxit Reader for Linux works fine, no need to use Wine
So does google-chrome, it even edits the forms.
Firefox fails, but prints a ? for every cyrillic letter

Im quite sure that this problem can be solved with some font knowlegde. Somehow it must be possible to find ut which Cyrillic font is used in the document, and then make some kind of font substitution in the system.

But weel, I found two working alternatives, so I do not need to fill in these documents by hand this summer :-)

Kjeld Flarup (kjeld-flarup) wrote :

I tested with this form: http://archive.mid.ru//bul_ns_en.nsf/uvedomlenie.pdf

Foxit Reader for Linux works fine, no need to use Wine
So does google-chrome, it even edits the forms.
Firefox fails, but prints a ? for every cyrillic letter

Im quite sure that this problem can be solved with some font knowlegde. Somehow it must be possible to find ut which Cyrillic font is used in the document, and then make some kind of font substitution in the system.

But weel, I found two working alternatives, so I do not need to fill in these documents by hand this summer :-)

Is there any hope to fix it properly?

Confirm the issue in Gnome 3.20.1 in Debian/Testing.

(In reply to Alexander from comment #24)
> So 8 years passed and no fix for this?

this is a gnome devs and they breaking my caps switch every new release ))
so the pdf is much harder to fix here, just use mupdf

tags: removed: vivid
Simplehuman (simplehuman) wrote :

Yakkety is also affected, adding tag "yakkety"

tags: removed: wily

Guy, do you have any updates?
I am experiencing the same issue with okular.

Okular version 0.25.0 (KDE 4.14.24)

I can assist with anything may help you to fix this bug.

poppler version 0.45.0

przekop (przekop) wrote :

Hello
I can confirm this bug with Polish characters on current version of Evince in Ubuntu 14.04 and 16.04
Same with documents created with Acrobat PDFMaker or LibreOffice Writer.
I found Master PDF Editor which works fine. I can fill forms and save pdf properly.

Same problem reproduced with displaying PDF form in fresh Firefox and Chrome web browsers, that use JS rendering. So the problem is in PDF document - PDF document don't embed non-cyrillic font letters in PDF file. For this cases is better to display symbols via some default font, instead of missing letters.

So can we add workaround for "warning: layoutText: cannot convert U+65E5" - replace font for this symbol to system default?

The same issue exists on Fedora 25 even if latest poppler 0.52 is compiled and installed.

Guys, can we set some reward for the hero who will solve this?
This bug seems rather difficult, since it remains for so many years. And, of course, it delivers lots of pain to russian and japanese users.
Are there something like Mozilla-Russia «Bug Bounty» program? http://mozilla-russia.org/contribute/bounty-en.html

You can create bounty for this for example here: https://freedomsponsors.org/

Andrej.Skvortzov, thanks for this link!
I created an issue and invite everyone to sponsor it:
https://freedomsponsors.org/issue/807/problem-with-cyrillic-and-japanese-at-pdf-forms-evince-okular

(In reply to fidanjan-karen from comment #35)
> https://freedomsponsors.org/issue/807/problem-with-cyrillic-and-japanese-at-
> pdf-forms-evince-okular

I've added myself as a sponsor to the bounty.

There's not even a link to this bugzilla in the bounty description. You're not making it easy for people to understand what that bounty is about.

Also, this is a universal issue about characters not available in the embedded fonts or default pdf fonts. This is not just about cyrillic and japanese. I'm also hit by this issue very often, and I use central european characters. But as long as the bounty description says only cyrillic and japanese, I'm not going to increase the reward. Please adjust.

(In reply to Kamil Páral from comment #37)
> There's not even a link to this bugzilla in the bounty description. You're
> not making it easy for people to understand what that bounty is about.
>
> Also, this is a universal issue about characters not available in the
> embedded fonts or default pdf fonts. This is not just about cyrillic and
> japanese. I'm also hit by this issue very often, and I use central european
> characters. But as long as the bounty description says only cyrillic and
> japanese, I'm not going to increase the reward. Please adjust.

Kamil, thanks for your comment!
Unfortunately, I don't see the way to change the title of the issue, but I wrote more general description and added links to this thread and the bug 627024 at bugzilla.gnome.org.

Confirm the issue in last Archlinux
KDE Frameworks 5.37.0
Qt 5.9.1 (built against 5.9.1)
Okular 1.2.0

(In reply to nick from comment #39)
> Confirm the issue in last Archlinux
> KDE Frameworks 5.37.0
> Qt 5.9.1 (built against 5.9.1)
> Okular 1.2.0

The last Foxitreader for Linux (2.4.1.0609)can correctly fill forms with Cyrilic

Confirming this on current Debian Testing with libpoppler 0.57.0, in frontends: evince, qpdfview, mupdf.

This bug is 9 years old, confirmed a hundred times and is still in status "NEW"? This is ridiculous.

You are wasting previous time of people working on poppler doing such a useless comment, please refrain from commenting on the future unless you can add something useful to the discussion.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/463.

Changed in poppler:
status: Confirmed → Unknown
olivebranch (olivebranch) wrote :

Fill the input fields in Evince with Latin characters then in LibreOffice Draw change them to whatever you want.

Tonal (tonal-promsoft) wrote :

poppler moved to gitlab

Changed in poppler:
importance: Medium → Unknown
Changed in poppler:
status: Unknown → New
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.