Created attachment 118328 [details]
checkbox bug - odt test file
This bug has been nagging me for a long time, only now am I filing a bug. Thus I am not sure when this bug first appeared. It might well be that this never really worked.
1. open checkbox bug.odt file in LO writer
2. click "Export Directly as PDF" icon
3. compare odt file and exported PDF
odt: checkbox has "✔"
pdf: checkbox has "x"
Should be identical. What the user sees should not be altered on export to PDF.
Created attachment 118329 [details]
checkbox bug - exported pdf
Created attachment 118330 [details]
screenshot showing the problem
TESTING with Ubuntu 14.04 + LO Version: 126.96.36.199.alpha1+
Build ID: 452b1872af72d7fb31101aa2fa35aeaf18e41a10
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-09-02_08:11:07
+ Evince (PDF Viewer)
(In reply to steve -_- from comment #0)
[following given steps]
> odt: checkbox has "✔"
> pdf: checkbox has "x"
Yes, behavior confirmed.
OS -> All
Might be different glyphs, or?
We're not talking about just an exported chunk of text here; we're talking about an *actual* checkbox widget that can be toggled-on and toggled-off inside both LibreOffice and the PDF viewer. Maybe this is just an implementation detail?
> Should be identical. What the user sees should not be altered on export to
Let's see what Jay thinks about the situation from a UX perspective -- I'll cc him.
I checked the pdf at < http://www.pdfill.com/example/pdf_filler_new.pdf > and it has three types of checkboxes - 1 with X, 1 with check and 1 with dot. So i guess it is possible for us to export it as a checkbox with a check.
(In reply to Yousuf (Jay) Philips from comment #4)
> ...So i guess it is possible for us to export it as a checkbox with a
If it's actually something we can change to have higher fidelity with the behavior in LO, then let's make it
Status -> NEW
Severity -> enhancement
bug still present in LibO 188.8.131.52.alpha0+
Build ID: e2f6c7f0d0cc14f851d7028ff846c5dc658a81c6
CPU Threads: 4; OS Version: Windows 6.29; UI Render: default;
TinderBox: Win-x86@42, Branch:master, Time: 2016-10-10_23:08:02
Locale: it-IT (it_IT); Calc: group
bug was already present in OOo 3.3.0 and LibO 3.3.3 as well so it's inherited from OOo
Possibly solved - see https://gerrit.libreoffice.org/74995
Yep, fixed for me - please check & verify if possible!
Not fixed for me: libo-master64~2019-07-03_06.33.11_LibreOfficeDev_184.108.40.206.alpha0_Win_x64.msi
I set to New. Please test.
Created attachment 152565 [details]
clip of export result, 0x2713 not used as basis of check box
Not yet correct (at least on Winodws builds).
Attachment 118328 [details] should not be used to test with of course.
Attaching a new document after changes, with a set of Form Designed checkboxes (default Liberation Serif fonts).
Also, resulting PDF export, and a screen clip of the PDF open in Adobe Reader.
Should note (that on Windows at least) the print preview also does not use the 0x2713, and like PDF export also gets a graphic object with a drawn "X" not a font glyph.
Windows 10 Home 64-bit en-US (1809)
Version: 220.127.116.11.alpha0+ (x64)
Build ID: a9885aed4ee65067613e5506771b6ae6b5e0bae0
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win;
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-07-04_01:38:09
Locale: en-US (en_US); UI-Language: en-US
Created attachment 152566 [details]
test doc from current 6.4.0alpah0+ master with patches
Created attachment 152567 [details]
result of direct Export to PDF (PDF dialog cleared of checks except no compression)
Ah! So this report is about the export with _disabled_ 'Create Form' support?
Then yes, this is not fixed. Didn't touch that code at all. ;)
(if that's indeed what's meant here, perhaps worth re-phrasing even the title - totally missed that from the description)
This is persisting when using ⌘P from within LO. That will open the default print dialog. In the bottom left of that dialog select "Save as PDF".
The resulting PDF has "x" instead of "✔".
Interestingly though, File > Export as > Export as PDF… with the option "Create PDF Form" does result in a correct PDF. I think that is new and improved behavior.
Retested macOS 10.15.3, LO 18.104.22.168.