You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@pdfbox.apache.org by Johannes Barre <jo...@billfront.com> on 2015/10/08 13:30:35 UTC
Weird issue with fonts in input fields after merging
Hello!
I have a weird issue. So, I have to PDFs. When I fill form fields in one of
them and save, everything looks fine. However, when I append this filled
PDF to another one, xpdf doesn't display the values anymore and complains
about missing fonts:
Syntax Error: Unknown font tag 'ProximaNova-Regular'
Syntax Error: Unknown font in field's DA string
Syntax Error: Unknown font tag 'ProximaNova-Regular'
Syntax Error: Unknown font in field's DA string
I'm using JRuby (9k), but I hope it's understandable for you. I put the
source & PDFs in this gist:
https://gist.github.com/iGEL/a8484f0bc44b03fa9de1 (Will delete it later,
once the issue is solved)
Other specs: pdfbox-app-1.8.10, openjdk 1.8.0_66, Debian Jessy inside of
Docker
As you can see, I use a special way to set the values. I had problems with
German umlauts using setValue and it also sometimes fails (Possibly related
to https://issues.apache.org/jira/browse/PDFBOX-1550, the message is the
same as in that bug)
The COVER_PAGE.pdf and BIW_FORM.pdf are the templates I'm using,
form_filled.pdf is just the BIW_FORM.pdf with 2 fields filled and merged is
COVER_PAGE.pdf and form_filled.pdf merged together.
The p in line 15 and 22 print out the DA value of the field and it's the
same for both files:
"/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # form_filled.pdf
"/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # merged.pdf
This font is according to pdffonts in both files:
$ pdffonts form_filled.pdf
name type encoding emb
sub uni object ID
------------------------------------ ----------------- ---------------- ---
--- --- ---------
NPQRGV+ProximaNova-Light Type 1C Custom yes
yes yes 124 0
*MHGLSX+ProximaNova-Regular Type 1C WinAnsi
yes yes yes 125 0*
NPQRGV+ProximaNova-Bold Type 1C Custom yes
yes yes 126 0
MHGLSX+Facit-Bold Type 1C Custom yes
yes yes 127 0
NPQRGV+ProximaNova-Bold Type 1C WinAnsi yes
yes yes 218 0
NPQRGV+ProximaNova-Light Type 1C WinAnsi yes
yes yes 219 0
ProximaNova-Bold Type 1C (OT) Custom yes
no no 8 0
ProximaNova-Light Type 1C (OT) Custom yes
no no 9 0
NPQRGV+ProximaNova-Bold Type 1C WinAnsi yes
yes yes 251 0
NPQRGV+ProximaNova-Light Type 1C WinAnsi yes
yes yes 252 0
NPQRGV+ProximaNova-Bold Type 1C WinAnsi yes
yes yes 254 0
NPQRGV+ProximaNova-Light Type 1C WinAnsi yes
yes yes 255 0
FJORTL+ProximaNova-Light CID Type 0C Identity-H yes
yes yes 165 0
NPQRGV+ProximaNova-Bold Type 1C WinAnsi yes
yes yes 259 0
NPQRGV+ProximaNova-Light Type 1C WinAnsi yes
yes yes 260 0
$pdffonts merged.pdf
name type encoding emb
sub uni object ID
------------------------------------ ----------------- ---------------- ---
--- --- ---------
AYOVHV+Facit-Bold Type 1C Custom yes
yes yes 131 0
AYOVHV+ProximaNova-Bold Type 1C Custom yes
yes yes 132 0
AYOVHV+ProximaNova-Light Type 1C Custom yes
yes yes 133 0
AYOVHV+ProximaNova-Semibold Type 1C WinAnsi yes
yes yes 134 0
ProximaNova-Light Type 1C (OT) Custom yes
no no 9 0
AYOVHV+ProximaNova-Light Type 1C WinAnsi yes
yes no 192 0
AYOVHV+ProximaNova-Light Type 1C WinAnsi yes
yes no 193 0
NPQRGV+ProximaNova-Light Type 1C Custom yes
yes yes 275 0
*MHGLSX+ProximaNova-Regular Type 1C WinAnsi
yes yes yes 276 0*
NPQRGV+ProximaNova-Bold Type 1C Custom yes
yes yes 277 0
MHGLSX+Facit-Bold Type 1C Custom yes
yes yes 278 0
NPQRGV+ProximaNova-Bold Type 1C WinAnsi yes
yes yes 437 0
NPQRGV+ProximaNova-Light Type 1C WinAnsi yes
yes yes 438 0
ProximaNova-Bold Type 1C (OT) Custom yes
no no 462 0
ProximaNova-Light Type 1C (OT) Custom yes
no no 512 0
NPQRGV+ProximaNova-Bold Type 1C WinAnsi yes
yes yes 500 0
NPQRGV+ProximaNova-Light Type 1C WinAnsi yes
yes yes 501 0
NPQRGV+ProximaNova-Bold Type 1C WinAnsi yes
yes yes 503 0
NPQRGV+ProximaNova-Light Type 1C WinAnsi yes
yes yes 504 0
FJORTL+ProximaNova-Light CID Type 0C Identity-H yes
yes yes 377 0
NPQRGV+ProximaNova-Bold Type 1C WinAnsi yes
yes yes 451 0
NPQRGV+ProximaNova-Light Type 1C WinAnsi yes
yes yes 452 0
Why are the field values not showing up and how can I fix that?
Thanks for your help!
Johannes
Re: Weird issue with fonts in input fields after merging
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi,
> Am 09.10.2015 um 18:28 schrieb Johannes Barre <jo...@billfront.com>:
>
> Hello Maruan!
>
> I don't want to push you, but even if you couldn't figure out everything,
> also intermediate results or even just ideas could be helpful.
>
> I experimented a bit more and found, that setValue sometimes works with
> umlauts and sometimes doesn't when I use setValue instead of my hack. So,
> with the BIW_FORM.pdf, they are scrambled, but with the umlauts_ok.pdf,
> they are fine. Any idea, why they are scrambled in the BIW_FORM.pdf? Do I
> need to convert the character encoding? How do I detect which encoding is
> required?
>
> If I could fix this issue, I probably could use setValue. When using
> setValue, the values show up in Acrobat Reader even when I merge the
> documents :D
Di you try that with 1.8.x or 2.0.0?
BR
Maruan
>
> Greets, Johannes
>
> On Thu, Oct 8, 2015 at 4:35 PM, Maruan Sahyoun <sa...@fileaffairs.de>
> wrote:
>
>> Hi,
>>
>>> Am 08.10.2015 um 16:31 schrieb Johannes Barre <
>> johannes.barre@billfront.com>:
>>>
>>> Hello!
>>>
>>> I just tried the 2.0 snapshot from yesterday and get this error:
>>>
>>> org/apache/pdfbox/pdmodel/font/PDType1CFont.java:283:in `encode':
>>> java.lang.UnsupportedOperationException: Not implemented: Type1C
>>
>> there is already a ticket for that.
>>
>> BR Maruan
>>
>>>
>>> Is that also true for 1.8.10 (just without the error) and could it be
>>> related to the problem?
>>>
>>> Greets, Johannes
>>>
>>> PS: I've also pushed a Java version of my code to the gist. It's probably
>>> as messy as my JRuby version, they're just experiments.
>>>
>>> On Thu, Oct 8, 2015 at 3:41 PM, Johannes Barre <
>> johannes.barre@billfront.com
>>>> wrote:
>>>
>>>> Hello Maruan!
>>>>
>>>> Thank again. I hope my last answer didn't sounded too aggressive
>> (written
>>>> communication is difficult). I'm grateful for any help!
>>>>
>>>> You brought up a good point, as a Linux user I've only checked with
>> Google
>>>> Chrome & xpdf (and I was referring to the xpdf). In the Acrobat Reader 9
>>>> (Linux) and XI (Win XP), the field values are not shown. So I got a new
>>>> problem :'(
>>>>
>>>> Greets, Johannes
>>>>
>>>> On Thu, Oct 8, 2015 at 3:00 PM, Maruan Sahyoun <sa...@fileaffairs.de>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>>> Am 08.10.2015 um 14:53 schrieb Johannes Barre <
>>>>>> johannes.barre@billfront.com>:
>>>>>>
>>>>>> Hello Maruan!
>>>>>>
>>>>>> Thank you for your reply.
>>>>>>
>>>>>> So, basically you say, the source PDFs aren't valid already? I've
>> asked
>>>>> and
>>>>>> they were created with Adobe InDesign, I would hope that Adobe knows
>>>>> how to
>>>>>> generate valid PDFs. :-/
>>>>>
>>>>> the PDFs are not invalid - that's not what I wanted to say.
>>>>>
>>>>>> But even so, why is everything looking good when I just fill in the
>>>>> fields
>>>>>> without merging it? It has the same issue with the fonts name and I
>>>>> filled
>>>>>> the field with the same method.
>>>>>
>>>>> when you say looking good - are you looking at it with Adobe Reader or
>>>>> XPDF or ….
>>>>>
>>>>> I can have a more in-depth look tonight - my comments were about the
>>>>> quick observations I made.
>>>>>
>>>>> BR
>>>>> Maruan
>>>>>
>>>>>> Greets, Johannes
>>>>>>
>>>>>> On Thu, Oct 8, 2015 at 2:35 PM, Maruan Sahyoun <
>> sahyoun@fileaffairs.de>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>>> Am 08.10.2015 um 13:30 schrieb Johannes Barre <
>>>>>>>> johannes.barre@billfront.com>:
>>>>>>>>
>>>>>>>> Hello!
>>>>>>>>
>>>>>>>> I have a weird issue. So, I have to PDFs. When I fill form fields in
>>>>> one
>>>>>>> of
>>>>>>>> them and save, everything looks fine. However, when I append this
>>>>> filled
>>>>>>>> PDF to another one, xpdf doesn't display the values anymore and
>>>>> complains
>>>>>>>> about missing fonts:
>>>>>>>>
>>>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
>>>>>>>> Syntax Error: Unknown font in field's DA string
>>>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
>>>>>>>> Syntax Error: Unknown font in field's DA string
>>>>>>>>
>>>>>>>> I'm using JRuby (9k), but I hope it's understandable for you. I put
>>>>> the
>>>>>>>> source & PDFs in this gist:
>>>>>>>> https://gist.github.com/iGEL/a8484f0bc44b03fa9de1 (Will delete it
>>>>> later,
>>>>>>>> once the issue is solved)
>>>>>>>>
>>>>>>>> Other specs: pdfbox-app-1.8.10, openjdk 1.8.0_66, Debian Jessy
>> inside
>>>>> of
>>>>>>>> Docker
>>>>>>>>
>>>>>>>> As you can see, I use a special way to set the values. I had
>> problems
>>>>>>> with
>>>>>>>> German umlauts using setValue and it also sometimes fails (Possibly
>>>>>>> related
>>>>>>>> to https://issues.apache.org/jira/browse/PDFBOX-1550, the message
>> is
>>>>> the
>>>>>>>> same as in that bug)
>>>>>>>
>>>>>>> setting the field value directly using
>>>>>>>
>>>>>>> form.getField(name).getDictionary.setItem(
>>>>>>> Java::OrgApachePdfboxCos::COSName::V,
>>>>>>> Java::OrgApachePdfboxCos::COSString.new(value)
>>>>>>> )
>>>>>>>
>>>>>>> will not update the visual appearance of the filed and as a result
>> the
>>>>>>> newly set value is not visible
>>>>>>>
>>>>>>>
>>>>>>>> The COVER_PAGE.pdf and BIW_FORM.pdf are the templates I'm using,
>>>>>>>> form_filled.pdf is just the BIW_FORM.pdf with 2 fields filled and
>>>>> merged
>>>>>>> is
>>>>>>>> COVER_PAGE.pdf and form_filled.pdf merged together.
>>>>>>>>
>>>>>>>> The p in line 15 and 22 print out the DA value of the field and it's
>>>>> the
>>>>>>>> same for both files:
>>>>>>>>
>>>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # form_filled.pdf
>>>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # merged.pdf
>>>>>>>
>>>>>>> the font resource is called /ProximaNova-Regular but that's not in
>> your
>>>>>>> PDF as the font which is in your PDF is called
>>>>> /MHGLSX+ProximaNova-Regular.
>>>>>>> In addition the issue with a font subset is that only certain
>>>>> characters
>>>>>>> are part of that subset. As a result some of the characters you need
>> to
>>>>>>> display your field value might not be within the subset.
>>>>>>>
>>>>>>> BR
>>>>>>> Maruan
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> This font is according to pdffonts in both files:
>>>>>>>>
>>>>>>>> $ pdffonts form_filled.pdf
>>>>>>>> name type encoding
>>>>>>> emb
>>>>>>>> sub uni object ID
>>>>>>>> ------------------------------------ -----------------
>>>>> ----------------
>>>>>>> ---
>>>>>>>> --- --- ---------
>>>>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
>>>>>>> yes
>>>>>>>> yes yes 124 0
>>>>>>>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
>>>>>>>> yes yes yes 125 0*
>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
>>>>>>> yes
>>>>>>>> yes yes 126 0
>>>>>>>> MHGLSX+Facit-Bold Type 1C Custom
>>>>>>> yes
>>>>>>>> yes yes 127 0
>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 218 0
>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 219 0
>>>>>>>> ProximaNova-Bold Type 1C (OT) Custom
>>>>>>> yes
>>>>>>>> no no 8 0
>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
>>>>>>> yes
>>>>>>>> no no 9 0
>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 251 0
>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 252 0
>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 254 0
>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 255 0
>>>>>>>> FJORTL+ProximaNova-Light CID Type 0C Identity-H
>>>>>>> yes
>>>>>>>> yes yes 165 0
>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 259 0
>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 260 0
>>>>>>>>
>>>>>>>> $pdffonts merged.pdf
>>>>>>>> name type encoding
>>>>>>> emb
>>>>>>>> sub uni object ID
>>>>>>>> ------------------------------------ -----------------
>>>>> ----------------
>>>>>>> ---
>>>>>>>> --- --- ---------
>>>>>>>> AYOVHV+Facit-Bold Type 1C Custom
>>>>>>> yes
>>>>>>>> yes yes 131 0
>>>>>>>> AYOVHV+ProximaNova-Bold Type 1C Custom
>>>>>>> yes
>>>>>>>> yes yes 132 0
>>>>>>>> AYOVHV+ProximaNova-Light Type 1C Custom
>>>>>>> yes
>>>>>>>> yes yes 133 0
>>>>>>>> AYOVHV+ProximaNova-Semibold Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 134 0
>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
>>>>>>> yes
>>>>>>>> no no 9 0
>>>>>>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes no 192 0
>>>>>>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes no 193 0
>>>>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
>>>>>>> yes
>>>>>>>> yes yes 275 0
>>>>>>>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
>>>>>>>> yes yes yes 276 0*
>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
>>>>>>> yes
>>>>>>>> yes yes 277 0
>>>>>>>> MHGLSX+Facit-Bold Type 1C Custom
>>>>>>> yes
>>>>>>>> yes yes 278 0
>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 437 0
>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 438 0
>>>>>>>> ProximaNova-Bold Type 1C (OT) Custom
>>>>>>> yes
>>>>>>>> no no 462 0
>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
>>>>>>> yes
>>>>>>>> no no 512 0
>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 500 0
>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 501 0
>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 503 0
>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 504 0
>>>>>>>> FJORTL+ProximaNova-Light CID Type 0C Identity-H
>>>>>>> yes
>>>>>>>> yes yes 377 0
>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 451 0
>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 452 0
>>>>>>>>
>>>>>>>> Why are the field values not showing up and how can I fix that?
>>>>>>>>
>>>>>>>> Thanks for your help!
>>>>>>>>
>>>>>>>> Johannes
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Weird issue with fonts in input fields after merging
Posted by Johannes Barre <jo...@billfront.com>.
Hello Maruan!
Awesome, thank you very much for all the help! :)
Greets, Johannes
On Fri, Oct 30, 2015 at 11:20 PM, Maruan Sahyoun <sa...@fileaffairs.de>
wrote:
> Hi,
>
> > Am 29.10.2015 um 10:44 schrieb Johannes Barre <
> johannes.barre@billfront.com>:
> >
> > Hello Maruan!
> >
> > Did you (or anyone else) had the chance to look at my issue? I know, it's
> > all voluntary work you guys do, so I feel bad keeping bugging you with my
> > issues. But I think, I'm so close to get everything working, so it would
> be
> > a shame to throw this away and try something different...
> >
> > To summarize the it: I have a PDF, which has on each page an input field
> > named page_num. I want to fill in the page number of the current page.
> You
> > suggested:
> >
> > For that to work each page_num field has to be an individual field as
> > otherwise they do share the same value. What you could do, if you need to
> > make the field a set of individual ones is to (roughly)
> >
> > - iterate the PDAnnotationWidgets
> > - get the COSDictionary
> > - create a new PDField with the COSDictionary and the original field as
> > parent
> > - set an individual field name
> >
> >
> > My implementation, which generates unstyled input fields, is here
> > (including PDFs):
> > https://gist.github.com/iGEL/a8484f0bc44b03fa9de1#file-test-java (as
> said
> > before, I haven't found a way to set the field parent with PDFBox 2.0)
> >
> > I would like to keep the original style (color + font). Maybe I can
> > decouple the widgets completely (not leave them as children to the
> original
> > field?).
>
>
> you need to set the default appearance on the field not on the widget like
> so:
>
> for (PDAnnotationWidget widget : list) {
> PDTextField kid = new PDTextField(form);
> kid.setDefaultAppearance(parent.getDefaultAppearance());
>
> COSDictionary dict = widget.getCOSObject();
> List widgets = new ArrayList();
> widgets.add(widget);
> kid.setWidgets(widgets);
> kid.setPartialName("page" + UUID.randomUUID().toString());
> kid.setValue(String.valueOf((int) (1 + Math.random()*10)));
> }
>
>
> BR
> Maruan
>
> >
> > Greets, Johannes
> >
> > On Thu, Oct 22, 2015 at 10:56 AM, Johannes Barre <
> > johannes.barre@billfront.com> wrote:
> >
> >> Hello!
> >>
> >> Sorry for the late reply, I had to do different tasks. But finally I've
> >> got back to this. The form now looks great, thank you for that!
> >>
> >> However, remember the solution for the page numbering you gave me here?
> >>
> https://issues.apache.org/jira/browse/PDFBOX-2980?focusedCommentId=14900931&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14900931
> >>
> >> That still works, but the numbers are showing up in black (the font
> >> doesn't look right as well). I tried to find the issue, but to me it
> looks
> >> fine. Maybe I did something wrong? Or maybe the coloring thingy doesn't
> >> work for child fields?
> >>
> >> In 1.8.10, PDField used to have a setParent() method, but it disappeared
> >> in 2.0.0. I haven't found an alternative, so I don't set the parent.
> Could
> >> that cause the problem?
> >>
> >> I translated my strategy into (crappy) Java for easier debugging, please
> >> find it here (together with the source and generated PDF):
> >> https://gist.github.com/iGEL/a8484f0bc44b03fa9de1#file-test-java
> >>
> >> Greets, Johannes
> >>
> >> On Thu, Oct 15, 2015 at 1:34 AM, Maruan Sahyoun <sahyoun@fileaffairs.de
> >
> >> wrote:
> >>
> >>> Hi Kevin,
> >>>> Am 14.10.2015 um 12:05 schrieb Johannes Barre <
> >>> johannes.barre@billfront.com>:
> >>>>
> >>>> Cool, thank you! :)
> >>>>
> >>>
> >>> I've committed support for text color - please give it a try: If there
> >>> are issues please add your comments to
> >>>
> >>> https://issues.apache.org/jira/browse/PDFBOX-3023
> >>>
> >>> BR
> >>> Maruan
> >>>
> >>>> On Wed, Oct 14, 2015 at 12:03 PM, Maruan Sahyoun <
> >>> sahyoun@fileaffairs.de>
> >>>> wrote:
> >>>>
> >>>>> Hi Johannes,
> >>>>>
> >>>>>
> >>>>>> Am 14.10.2015 um 11:51 schrieb Johannes Barre <
> >>>>> johannes.barre@billfront.com>:
> >>>>>>
> >>>>>> Hello Maruan!
> >>>>>>
> >>>>>> Thank you for your help. I ported my real app to use the
> >>>>>> pdfbox-app-2.0.0-20151010.170237-1722.jar snapshot. The fields are
> >>> filled
> >>>>>> correctly and show up in all programs I tried.
> >>>>>>
> >>>>>> However, somehow the text color in the fields is black. I spend
> quite
> >>>>> some
> >>>>>> time investigating why, but my knowledge of PDF internals is just
> too
> >>>>>> limited. The text fields have a DA value of "/ProximaNova-Regular 9
> Tf
> >>>>>> 0.019 0.305 0.627 rg", and I assume, these three numbers are the RGB
> >>>>> values
> >>>>>> on a scale from 0 to 1. That would give me the color #054ea1, which
> is
> >>>>>> correct. So why is it showing up in black? When focus the field in
> >>>>>> AcrobatReader, it changes to the correct blue, so probably some
> other
> >>>>> value
> >>>>>> is responsible for the non-focused color. I wasn't able to figure
> out,
> >>>>>> which.
> >>>>>>
> >>>>>
> >>>>> the reason is unfortunately very simple - the color setting in the DA
> >>>>> string is not (yet) respected when creating the appearance stream
> i.e.
> >>> the
> >>>>> visual presentation of the field.
> >>>>>
> >>>>> I've created https://issues.apache.org/jira/browse/PDFBOX-3023 for
> >>> that.
> >>>>>
> >>>>> BR
> >>>>> Maruan
> >>>>>
> >>>>>
> >>>>>> Greets, Johannes
> >>>>>>
> >>>>>> On Fri, Oct 9, 2015 at 8:05 PM, Maruan Sahyoun <
> >>> sahyoun@fileaffairs.de>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>>> Am 09.10.2015 um 18:28 schrieb Johannes Barre <
> >>>>>>> johannes.barre@billfront.com>:
> >>>>>>>>
> >>>>>>>> Hello Maruan!
> >>>>>>>>
> >>>>>>>> I don't want to push you, but even if you couldn't figure out
> >>>>> everything,
> >>>>>>>> also intermediate results or even just ideas could be helpful.
> >>>>>>>>
> >>>>>>>> I experimented a bit more and found, that setValue sometimes works
> >>> with
> >>>>>>>> umlauts and sometimes doesn't when I use setValue instead of my
> >>> hack.
> >>>>> So,
> >>>>>>>> with the BIW_FORM.pdf, they are scrambled, but with the
> >>> umlauts_ok.pdf,
> >>>>>>>> they are fine. Any idea, why they are scrambled in the
> BIW_FORM.pdf?
> >>>>> Do I
> >>>>>>>> need to convert the character encoding? How do I detect which
> >>> encoding
> >>>>> is
> >>>>>>>> required?
> >>>>>>>>
> >>>>>>>
> >>>>>>> the 1.8 (and previous) version were not really dealing correctly
> with
> >>>>>>> character encodings specially if the font is subset. 2.0 does that
> >>>>>>> correctly. I did a quick hack to support encode() for Type 1 C
> fonts
> >>> and
> >>>>>>> after that your form works fine even with the umlaut.
> >>>>>>>
> >>>>>>> I've created https://issues.apache.org/jira/browse/PDFBOX-3016 <
> >>>>>>> https://issues.apache.org/jira/browse/PDFBOX-3016> for that.
> >>>>>>>
> >>>>>>> BR
> >>>>>>> Maruan
> >>>>>>>
> >>>>>>>> If I could fix this issue, I probably could use setValue. When
> using
> >>>>>>>> setValue, the values show up in Acrobat Reader even when I merge
> the
> >>>>>>>> documents :D
> >>>>>>>>
> >>>>>>>> Greets, Johannes
> >>>>>>>>
> >>>>>>>> On Thu, Oct 8, 2015 at 4:35 PM, Maruan Sahyoun <
> >>> sahyoun@fileaffairs.de
> >>>>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>>> Am 08.10.2015 um 16:31 schrieb Johannes Barre <
> >>>>>>>>> johannes.barre@billfront.com>:
> >>>>>>>>>>
> >>>>>>>>>> Hello!
> >>>>>>>>>>
> >>>>>>>>>> I just tried the 2.0 snapshot from yesterday and get this error:
> >>>>>>>>>>
> >>>>>>>>>> org/apache/pdfbox/pdmodel/font/PDType1CFont.java:283:in
> `encode':
> >>>>>>>>>> java.lang.UnsupportedOperationException: Not implemented: Type1C
> >>>>>>>>>
> >>>>>>>>> there is already a ticket for that.
> >>>>>>>>>
> >>>>>>>>> BR Maruan
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Is that also true for 1.8.10 (just without the error) and could
> >>> it be
> >>>>>>>>>> related to the problem?
> >>>>>>>>>>
> >>>>>>>>>> Greets, Johannes
> >>>>>>>>>>
> >>>>>>>>>> PS: I've also pushed a Java version of my code to the gist. It's
> >>>>>>> probably
> >>>>>>>>>> as messy as my JRuby version, they're just experiments.
> >>>>>>>>>>
> >>>>>>>>>> On Thu, Oct 8, 2015 at 3:41 PM, Johannes Barre <
> >>>>>>>>> johannes.barre@billfront.com
> >>>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hello Maruan!
> >>>>>>>>>>>
> >>>>>>>>>>> Thank again. I hope my last answer didn't sounded too
> aggressive
> >>>>>>>>> (written
> >>>>>>>>>>> communication is difficult). I'm grateful for any help!
> >>>>>>>>>>>
> >>>>>>>>>>> You brought up a good point, as a Linux user I've only checked
> >>> with
> >>>>>>>>> Google
> >>>>>>>>>>> Chrome & xpdf (and I was referring to the xpdf). In the Acrobat
> >>>>>>> Reader 9
> >>>>>>>>>>> (Linux) and XI (Win XP), the field values are not shown. So I
> >>> got a
> >>>>>>> new
> >>>>>>>>>>> problem :'(
> >>>>>>>>>>>
> >>>>>>>>>>> Greets, Johannes
> >>>>>>>>>>>
> >>>>>>>>>>> On Thu, Oct 8, 2015 at 3:00 PM, Maruan Sahyoun <
> >>>>>>> sahyoun@fileaffairs.de>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi,
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> Am 08.10.2015 um 14:53 schrieb Johannes Barre <
> >>>>>>>>>>>>> johannes.barre@billfront.com>:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hello Maruan!
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thank you for your reply.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So, basically you say, the source PDFs aren't valid already?
> >>> I've
> >>>>>>>>> asked
> >>>>>>>>>>>> and
> >>>>>>>>>>>>> they were created with Adobe InDesign, I would hope that
> Adobe
> >>>>> knows
> >>>>>>>>>>>> how to
> >>>>>>>>>>>>> generate valid PDFs. :-/
> >>>>>>>>>>>>
> >>>>>>>>>>>> the PDFs are not invalid - that's not what I wanted to say.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> But even so, why is everything looking good when I just fill
> in
> >>>>> the
> >>>>>>>>>>>> fields
> >>>>>>>>>>>>> without merging it? It has the same issue with the fonts name
> >>> and
> >>>>> I
> >>>>>>>>>>>> filled
> >>>>>>>>>>>>> the field with the same method.
> >>>>>>>>>>>>
> >>>>>>>>>>>> when you say looking good - are you looking at it with Adobe
> >>> Reader
> >>>>>>> or
> >>>>>>>>>>>> XPDF or ….
> >>>>>>>>>>>>
> >>>>>>>>>>>> I can have a more in-depth look tonight - my comments were
> about
> >>>>> the
> >>>>>>>>>>>> quick observations I made.
> >>>>>>>>>>>>
> >>>>>>>>>>>> BR
> >>>>>>>>>>>> Maruan
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Greets, Johannes
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Thu, Oct 8, 2015 at 2:35 PM, Maruan Sahyoun <
> >>>>>>>>> sahyoun@fileaffairs.de>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Am 08.10.2015 um 13:30 schrieb Johannes Barre <
> >>>>>>>>>>>>>>> johannes.barre@billfront.com>:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hello!
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I have a weird issue. So, I have to PDFs. When I fill form
> >>>>> fields
> >>>>>>> in
> >>>>>>>>>>>> one
> >>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>> them and save, everything looks fine. However, when I
> append
> >>>>> this
> >>>>>>>>>>>> filled
> >>>>>>>>>>>>>>> PDF to another one, xpdf doesn't display the values anymore
> >>> and
> >>>>>>>>>>>> complains
> >>>>>>>>>>>>>>> about missing fonts:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
> >>>>>>>>>>>>>>> Syntax Error: Unknown font in field's DA string
> >>>>>>>>>>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
> >>>>>>>>>>>>>>> Syntax Error: Unknown font in field's DA string
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I'm using JRuby (9k), but I hope it's understandable for
> >>> you. I
> >>>>>>> put
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>> source & PDFs in this gist:
> >>>>>>>>>>>>>>> https://gist.github.com/iGEL/a8484f0bc44b03fa9de1 (Will
> >>> delete
> >>>>> it
> >>>>>>>>>>>> later,
> >>>>>>>>>>>>>>> once the issue is solved)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Other specs: pdfbox-app-1.8.10, openjdk 1.8.0_66, Debian
> >>> Jessy
> >>>>>>>>> inside
> >>>>>>>>>>>> of
> >>>>>>>>>>>>>>> Docker
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> As you can see, I use a special way to set the values. I
> had
> >>>>>>>>> problems
> >>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>> German umlauts using setValue and it also sometimes fails
> >>>>>>> (Possibly
> >>>>>>>>>>>>>> related
> >>>>>>>>>>>>>>> to https://issues.apache.org/jira/browse/PDFBOX-1550, the
> >>>>> message
> >>>>>>>>> is
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>> same as in that bug)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> setting the field value directly using
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> form.getField(name).getDictionary.setItem(
> >>>>>>>>>>>>>> Java::OrgApachePdfboxCos::COSName::V,
> >>>>>>>>>>>>>> Java::OrgApachePdfboxCos::COSString.new(value)
> >>>>>>>>>>>>>> )
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> will not update the visual appearance of the filed and as a
> >>>>> result
> >>>>>>>>> the
> >>>>>>>>>>>>>> newly set value is not visible
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The COVER_PAGE.pdf and BIW_FORM.pdf are the templates I'm
> >>> using,
> >>>>>>>>>>>>>>> form_filled.pdf is just the BIW_FORM.pdf with 2 fields
> filled
> >>>>> and
> >>>>>>>>>>>> merged
> >>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>> COVER_PAGE.pdf and form_filled.pdf merged together.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The p in line 15 and 22 print out the DA value of the field
> >>> and
> >>>>>>> it's
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>> same for both files:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" #
> >>>>> form_filled.pdf
> >>>>>>>>>>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" #
> merged.pdf
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> the font resource is called /ProximaNova-Regular but that's
> >>> not
> >>>>> in
> >>>>>>>>> your
> >>>>>>>>>>>>>> PDF as the font which is in your PDF is called
> >>>>>>>>>>>> /MHGLSX+ProximaNova-Regular.
> >>>>>>>>>>>>>> In addition the issue with a font subset is that only
> certain
> >>>>>>>>>>>> characters
> >>>>>>>>>>>>>> are part of that subset. As a result some of the characters
> >>> you
> >>>>>>> need
> >>>>>>>>> to
> >>>>>>>>>>>>>> display your field value might not be within the subset.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> BR
> >>>>>>>>>>>>>> Maruan
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This font is according to pdffonts in both files:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> $ pdffonts form_filled.pdf
> >>>>>>>>>>>>>>> name type
> >>> encoding
> >>>>>>>>>>>>>> emb
> >>>>>>>>>>>>>>> sub uni object ID
> >>>>>>>>>>>>>>> ------------------------------------ -----------------
> >>>>>>>>>>>> ----------------
> >>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>> --- --- ---------
> >>>>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
> Custom
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 124 0
> >>>>>>>>>>>>>>> *MHGLSX+ProximaNova-Regular Type 1C
> >>> WinAnsi
> >>>>>>>>>>>>>>> yes yes yes 125 0*
> >>>>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
> Custom
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 126 0
> >>>>>>>>>>>>>>> MHGLSX+Facit-Bold Type 1C
> Custom
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 127 0
> >>>>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
> >>> WinAnsi
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 218 0
> >>>>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
> >>> WinAnsi
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 219 0
> >>>>>>>>>>>>>>> ProximaNova-Bold Type 1C (OT)
> Custom
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> no no 8 0
> >>>>>>>>>>>>>>> ProximaNova-Light Type 1C (OT)
> Custom
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> no no 9 0
> >>>>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
> >>> WinAnsi
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 251 0
> >>>>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
> >>> WinAnsi
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 252 0
> >>>>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
> >>> WinAnsi
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 254 0
> >>>>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
> >>> WinAnsi
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 255 0
> >>>>>>>>>>>>>>> FJORTL+ProximaNova-Light CID Type 0C
> >>>>> Identity-H
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 165 0
> >>>>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
> >>> WinAnsi
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 259 0
> >>>>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
> >>> WinAnsi
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 260 0
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> $pdffonts merged.pdf
> >>>>>>>>>>>>>>> name type
> >>> encoding
> >>>>>>>>>>>>>> emb
> >>>>>>>>>>>>>>> sub uni object ID
> >>>>>>>>>>>>>>> ------------------------------------ -----------------
> >>>>>>>>>>>> ----------------
> >>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>> --- --- ---------
> >>>>>>>>>>>>>>> AYOVHV+Facit-Bold Type 1C
> Custom
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 131 0
> >>>>>>>>>>>>>>> AYOVHV+ProximaNova-Bold Type 1C
> Custom
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 132 0
> >>>>>>>>>>>>>>> AYOVHV+ProximaNova-Light Type 1C
> Custom
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 133 0
> >>>>>>>>>>>>>>> AYOVHV+ProximaNova-Semibold Type 1C
> >>> WinAnsi
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 134 0
> >>>>>>>>>>>>>>> ProximaNova-Light Type 1C (OT)
> Custom
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> no no 9 0
> >>>>>>>>>>>>>>> AYOVHV+ProximaNova-Light Type 1C
> >>> WinAnsi
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes no 192 0
> >>>>>>>>>>>>>>> AYOVHV+ProximaNova-Light Type 1C
> >>> WinAnsi
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes no 193 0
> >>>>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
> Custom
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 275 0
> >>>>>>>>>>>>>>> *MHGLSX+ProximaNova-Regular Type 1C
> >>> WinAnsi
> >>>>>>>>>>>>>>> yes yes yes 276 0*
> >>>>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
> Custom
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 277 0
> >>>>>>>>>>>>>>> MHGLSX+Facit-Bold Type 1C
> Custom
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 278 0
> >>>>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
> >>> WinAnsi
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 437 0
> >>>>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
> >>> WinAnsi
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 438 0
> >>>>>>>>>>>>>>> ProximaNova-Bold Type 1C (OT)
> Custom
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> no no 462 0
> >>>>>>>>>>>>>>> ProximaNova-Light Type 1C (OT)
> Custom
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> no no 512 0
> >>>>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
> >>> WinAnsi
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 500 0
> >>>>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
> >>> WinAnsi
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 501 0
> >>>>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
> >>> WinAnsi
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 503 0
> >>>>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
> >>> WinAnsi
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 504 0
> >>>>>>>>>>>>>>> FJORTL+ProximaNova-Light CID Type 0C
> >>>>> Identity-H
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 377 0
> >>>>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
> >>> WinAnsi
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 451 0
> >>>>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
> >>> WinAnsi
> >>>>>>>>>>>>>> yes
> >>>>>>>>>>>>>>> yes yes 452 0
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Why are the field values not showing up and how can I fix
> >>> that?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Thanks for your help!
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Johannes
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> >>>>>>>>>>>>>> For additional commands, e-mail:
> users-help@pdfbox.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> >>>>>>>>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> >>>>>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> >>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>>>>
> >>>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> >>> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>>
> >>>
> >>
>
>
Re: Weird issue with fonts in input fields after merging
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi,
> Am 29.10.2015 um 10:44 schrieb Johannes Barre <jo...@billfront.com>:
>
> Hello Maruan!
>
> Did you (or anyone else) had the chance to look at my issue? I know, it's
> all voluntary work you guys do, so I feel bad keeping bugging you with my
> issues. But I think, I'm so close to get everything working, so it would be
> a shame to throw this away and try something different...
>
> To summarize the it: I have a PDF, which has on each page an input field
> named page_num. I want to fill in the page number of the current page. You
> suggested:
>
> For that to work each page_num field has to be an individual field as
> otherwise they do share the same value. What you could do, if you need to
> make the field a set of individual ones is to (roughly)
>
> - iterate the PDAnnotationWidgets
> - get the COSDictionary
> - create a new PDField with the COSDictionary and the original field as
> parent
> - set an individual field name
>
>
> My implementation, which generates unstyled input fields, is here
> (including PDFs):
> https://gist.github.com/iGEL/a8484f0bc44b03fa9de1#file-test-java (as said
> before, I haven't found a way to set the field parent with PDFBox 2.0)
>
> I would like to keep the original style (color + font). Maybe I can
> decouple the widgets completely (not leave them as children to the original
> field?).
you need to set the default appearance on the field not on the widget like so:
for (PDAnnotationWidget widget : list) {
PDTextField kid = new PDTextField(form);
kid.setDefaultAppearance(parent.getDefaultAppearance());
COSDictionary dict = widget.getCOSObject();
List widgets = new ArrayList();
widgets.add(widget);
kid.setWidgets(widgets);
kid.setPartialName("page" + UUID.randomUUID().toString());
kid.setValue(String.valueOf((int) (1 + Math.random()*10)));
}
BR
Maruan
>
> Greets, Johannes
>
> On Thu, Oct 22, 2015 at 10:56 AM, Johannes Barre <
> johannes.barre@billfront.com> wrote:
>
>> Hello!
>>
>> Sorry for the late reply, I had to do different tasks. But finally I've
>> got back to this. The form now looks great, thank you for that!
>>
>> However, remember the solution for the page numbering you gave me here?
>> https://issues.apache.org/jira/browse/PDFBOX-2980?focusedCommentId=14900931&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14900931
>>
>> That still works, but the numbers are showing up in black (the font
>> doesn't look right as well). I tried to find the issue, but to me it looks
>> fine. Maybe I did something wrong? Or maybe the coloring thingy doesn't
>> work for child fields?
>>
>> In 1.8.10, PDField used to have a setParent() method, but it disappeared
>> in 2.0.0. I haven't found an alternative, so I don't set the parent. Could
>> that cause the problem?
>>
>> I translated my strategy into (crappy) Java for easier debugging, please
>> find it here (together with the source and generated PDF):
>> https://gist.github.com/iGEL/a8484f0bc44b03fa9de1#file-test-java
>>
>> Greets, Johannes
>>
>> On Thu, Oct 15, 2015 at 1:34 AM, Maruan Sahyoun <sa...@fileaffairs.de>
>> wrote:
>>
>>> Hi Kevin,
>>>> Am 14.10.2015 um 12:05 schrieb Johannes Barre <
>>> johannes.barre@billfront.com>:
>>>>
>>>> Cool, thank you! :)
>>>>
>>>
>>> I've committed support for text color - please give it a try: If there
>>> are issues please add your comments to
>>>
>>> https://issues.apache.org/jira/browse/PDFBOX-3023
>>>
>>> BR
>>> Maruan
>>>
>>>> On Wed, Oct 14, 2015 at 12:03 PM, Maruan Sahyoun <
>>> sahyoun@fileaffairs.de>
>>>> wrote:
>>>>
>>>>> Hi Johannes,
>>>>>
>>>>>
>>>>>> Am 14.10.2015 um 11:51 schrieb Johannes Barre <
>>>>> johannes.barre@billfront.com>:
>>>>>>
>>>>>> Hello Maruan!
>>>>>>
>>>>>> Thank you for your help. I ported my real app to use the
>>>>>> pdfbox-app-2.0.0-20151010.170237-1722.jar snapshot. The fields are
>>> filled
>>>>>> correctly and show up in all programs I tried.
>>>>>>
>>>>>> However, somehow the text color in the fields is black. I spend quite
>>>>> some
>>>>>> time investigating why, but my knowledge of PDF internals is just too
>>>>>> limited. The text fields have a DA value of "/ProximaNova-Regular 9 Tf
>>>>>> 0.019 0.305 0.627 rg", and I assume, these three numbers are the RGB
>>>>> values
>>>>>> on a scale from 0 to 1. That would give me the color #054ea1, which is
>>>>>> correct. So why is it showing up in black? When focus the field in
>>>>>> AcrobatReader, it changes to the correct blue, so probably some other
>>>>> value
>>>>>> is responsible for the non-focused color. I wasn't able to figure out,
>>>>>> which.
>>>>>>
>>>>>
>>>>> the reason is unfortunately very simple - the color setting in the DA
>>>>> string is not (yet) respected when creating the appearance stream i.e.
>>> the
>>>>> visual presentation of the field.
>>>>>
>>>>> I've created https://issues.apache.org/jira/browse/PDFBOX-3023 for
>>> that.
>>>>>
>>>>> BR
>>>>> Maruan
>>>>>
>>>>>
>>>>>> Greets, Johannes
>>>>>>
>>>>>> On Fri, Oct 9, 2015 at 8:05 PM, Maruan Sahyoun <
>>> sahyoun@fileaffairs.de>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>> Am 09.10.2015 um 18:28 schrieb Johannes Barre <
>>>>>>> johannes.barre@billfront.com>:
>>>>>>>>
>>>>>>>> Hello Maruan!
>>>>>>>>
>>>>>>>> I don't want to push you, but even if you couldn't figure out
>>>>> everything,
>>>>>>>> also intermediate results or even just ideas could be helpful.
>>>>>>>>
>>>>>>>> I experimented a bit more and found, that setValue sometimes works
>>> with
>>>>>>>> umlauts and sometimes doesn't when I use setValue instead of my
>>> hack.
>>>>> So,
>>>>>>>> with the BIW_FORM.pdf, they are scrambled, but with the
>>> umlauts_ok.pdf,
>>>>>>>> they are fine. Any idea, why they are scrambled in the BIW_FORM.pdf?
>>>>> Do I
>>>>>>>> need to convert the character encoding? How do I detect which
>>> encoding
>>>>> is
>>>>>>>> required?
>>>>>>>>
>>>>>>>
>>>>>>> the 1.8 (and previous) version were not really dealing correctly with
>>>>>>> character encodings specially if the font is subset. 2.0 does that
>>>>>>> correctly. I did a quick hack to support encode() for Type 1 C fonts
>>> and
>>>>>>> after that your form works fine even with the umlaut.
>>>>>>>
>>>>>>> I've created https://issues.apache.org/jira/browse/PDFBOX-3016 <
>>>>>>> https://issues.apache.org/jira/browse/PDFBOX-3016> for that.
>>>>>>>
>>>>>>> BR
>>>>>>> Maruan
>>>>>>>
>>>>>>>> If I could fix this issue, I probably could use setValue. When using
>>>>>>>> setValue, the values show up in Acrobat Reader even when I merge the
>>>>>>>> documents :D
>>>>>>>>
>>>>>>>> Greets, Johannes
>>>>>>>>
>>>>>>>> On Thu, Oct 8, 2015 at 4:35 PM, Maruan Sahyoun <
>>> sahyoun@fileaffairs.de
>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>> Am 08.10.2015 um 16:31 schrieb Johannes Barre <
>>>>>>>>> johannes.barre@billfront.com>:
>>>>>>>>>>
>>>>>>>>>> Hello!
>>>>>>>>>>
>>>>>>>>>> I just tried the 2.0 snapshot from yesterday and get this error:
>>>>>>>>>>
>>>>>>>>>> org/apache/pdfbox/pdmodel/font/PDType1CFont.java:283:in `encode':
>>>>>>>>>> java.lang.UnsupportedOperationException: Not implemented: Type1C
>>>>>>>>>
>>>>>>>>> there is already a ticket for that.
>>>>>>>>>
>>>>>>>>> BR Maruan
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Is that also true for 1.8.10 (just without the error) and could
>>> it be
>>>>>>>>>> related to the problem?
>>>>>>>>>>
>>>>>>>>>> Greets, Johannes
>>>>>>>>>>
>>>>>>>>>> PS: I've also pushed a Java version of my code to the gist. It's
>>>>>>> probably
>>>>>>>>>> as messy as my JRuby version, they're just experiments.
>>>>>>>>>>
>>>>>>>>>> On Thu, Oct 8, 2015 at 3:41 PM, Johannes Barre <
>>>>>>>>> johannes.barre@billfront.com
>>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello Maruan!
>>>>>>>>>>>
>>>>>>>>>>> Thank again. I hope my last answer didn't sounded too aggressive
>>>>>>>>> (written
>>>>>>>>>>> communication is difficult). I'm grateful for any help!
>>>>>>>>>>>
>>>>>>>>>>> You brought up a good point, as a Linux user I've only checked
>>> with
>>>>>>>>> Google
>>>>>>>>>>> Chrome & xpdf (and I was referring to the xpdf). In the Acrobat
>>>>>>> Reader 9
>>>>>>>>>>> (Linux) and XI (Win XP), the field values are not shown. So I
>>> got a
>>>>>>> new
>>>>>>>>>>> problem :'(
>>>>>>>>>>>
>>>>>>>>>>> Greets, Johannes
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Oct 8, 2015 at 3:00 PM, Maruan Sahyoun <
>>>>>>> sahyoun@fileaffairs.de>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>>>> Am 08.10.2015 um 14:53 schrieb Johannes Barre <
>>>>>>>>>>>>> johannes.barre@billfront.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hello Maruan!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you for your reply.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, basically you say, the source PDFs aren't valid already?
>>> I've
>>>>>>>>> asked
>>>>>>>>>>>> and
>>>>>>>>>>>>> they were created with Adobe InDesign, I would hope that Adobe
>>>>> knows
>>>>>>>>>>>> how to
>>>>>>>>>>>>> generate valid PDFs. :-/
>>>>>>>>>>>>
>>>>>>>>>>>> the PDFs are not invalid - that's not what I wanted to say.
>>>>>>>>>>>>
>>>>>>>>>>>>> But even so, why is everything looking good when I just fill in
>>>>> the
>>>>>>>>>>>> fields
>>>>>>>>>>>>> without merging it? It has the same issue with the fonts name
>>> and
>>>>> I
>>>>>>>>>>>> filled
>>>>>>>>>>>>> the field with the same method.
>>>>>>>>>>>>
>>>>>>>>>>>> when you say looking good - are you looking at it with Adobe
>>> Reader
>>>>>>> or
>>>>>>>>>>>> XPDF or ….
>>>>>>>>>>>>
>>>>>>>>>>>> I can have a more in-depth look tonight - my comments were about
>>>>> the
>>>>>>>>>>>> quick observations I made.
>>>>>>>>>>>>
>>>>>>>>>>>> BR
>>>>>>>>>>>> Maruan
>>>>>>>>>>>>
>>>>>>>>>>>>> Greets, Johannes
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Oct 8, 2015 at 2:35 PM, Maruan Sahyoun <
>>>>>>>>> sahyoun@fileaffairs.de>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Am 08.10.2015 um 13:30 schrieb Johannes Barre <
>>>>>>>>>>>>>>> johannes.barre@billfront.com>:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have a weird issue. So, I have to PDFs. When I fill form
>>>>> fields
>>>>>>> in
>>>>>>>>>>>> one
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> them and save, everything looks fine. However, when I append
>>>>> this
>>>>>>>>>>>> filled
>>>>>>>>>>>>>>> PDF to another one, xpdf doesn't display the values anymore
>>> and
>>>>>>>>>>>> complains
>>>>>>>>>>>>>>> about missing fonts:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
>>>>>>>>>>>>>>> Syntax Error: Unknown font in field's DA string
>>>>>>>>>>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
>>>>>>>>>>>>>>> Syntax Error: Unknown font in field's DA string
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm using JRuby (9k), but I hope it's understandable for
>>> you. I
>>>>>>> put
>>>>>>>>>>>> the
>>>>>>>>>>>>>>> source & PDFs in this gist:
>>>>>>>>>>>>>>> https://gist.github.com/iGEL/a8484f0bc44b03fa9de1 (Will
>>> delete
>>>>> it
>>>>>>>>>>>> later,
>>>>>>>>>>>>>>> once the issue is solved)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Other specs: pdfbox-app-1.8.10, openjdk 1.8.0_66, Debian
>>> Jessy
>>>>>>>>> inside
>>>>>>>>>>>> of
>>>>>>>>>>>>>>> Docker
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As you can see, I use a special way to set the values. I had
>>>>>>>>> problems
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> German umlauts using setValue and it also sometimes fails
>>>>>>> (Possibly
>>>>>>>>>>>>>> related
>>>>>>>>>>>>>>> to https://issues.apache.org/jira/browse/PDFBOX-1550, the
>>>>> message
>>>>>>>>> is
>>>>>>>>>>>> the
>>>>>>>>>>>>>>> same as in that bug)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> setting the field value directly using
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> form.getField(name).getDictionary.setItem(
>>>>>>>>>>>>>> Java::OrgApachePdfboxCos::COSName::V,
>>>>>>>>>>>>>> Java::OrgApachePdfboxCos::COSString.new(value)
>>>>>>>>>>>>>> )
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> will not update the visual appearance of the filed and as a
>>>>> result
>>>>>>>>> the
>>>>>>>>>>>>>> newly set value is not visible
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The COVER_PAGE.pdf and BIW_FORM.pdf are the templates I'm
>>> using,
>>>>>>>>>>>>>>> form_filled.pdf is just the BIW_FORM.pdf with 2 fields filled
>>>>> and
>>>>>>>>>>>> merged
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>> COVER_PAGE.pdf and form_filled.pdf merged together.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The p in line 15 and 22 print out the DA value of the field
>>> and
>>>>>>> it's
>>>>>>>>>>>> the
>>>>>>>>>>>>>>> same for both files:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" #
>>>>> form_filled.pdf
>>>>>>>>>>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # merged.pdf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> the font resource is called /ProximaNova-Regular but that's
>>> not
>>>>> in
>>>>>>>>> your
>>>>>>>>>>>>>> PDF as the font which is in your PDF is called
>>>>>>>>>>>> /MHGLSX+ProximaNova-Regular.
>>>>>>>>>>>>>> In addition the issue with a font subset is that only certain
>>>>>>>>>>>> characters
>>>>>>>>>>>>>> are part of that subset. As a result some of the characters
>>> you
>>>>>>> need
>>>>>>>>> to
>>>>>>>>>>>>>> display your field value might not be within the subset.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> BR
>>>>>>>>>>>>>> Maruan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This font is according to pdffonts in both files:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> $ pdffonts form_filled.pdf
>>>>>>>>>>>>>>> name type
>>> encoding
>>>>>>>>>>>>>> emb
>>>>>>>>>>>>>>> sub uni object ID
>>>>>>>>>>>>>>> ------------------------------------ -----------------
>>>>>>>>>>>> ----------------
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>> --- --- ---------
>>>>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 124 0
>>>>>>>>>>>>>>> *MHGLSX+ProximaNova-Regular Type 1C
>>> WinAnsi
>>>>>>>>>>>>>>> yes yes yes 125 0*
>>>>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 126 0
>>>>>>>>>>>>>>> MHGLSX+Facit-Bold Type 1C Custom
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 127 0
>>>>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
>>> WinAnsi
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 218 0
>>>>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
>>> WinAnsi
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 219 0
>>>>>>>>>>>>>>> ProximaNova-Bold Type 1C (OT) Custom
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> no no 8 0
>>>>>>>>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> no no 9 0
>>>>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
>>> WinAnsi
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 251 0
>>>>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
>>> WinAnsi
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 252 0
>>>>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
>>> WinAnsi
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 254 0
>>>>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
>>> WinAnsi
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 255 0
>>>>>>>>>>>>>>> FJORTL+ProximaNova-Light CID Type 0C
>>>>> Identity-H
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 165 0
>>>>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
>>> WinAnsi
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 259 0
>>>>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
>>> WinAnsi
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 260 0
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> $pdffonts merged.pdf
>>>>>>>>>>>>>>> name type
>>> encoding
>>>>>>>>>>>>>> emb
>>>>>>>>>>>>>>> sub uni object ID
>>>>>>>>>>>>>>> ------------------------------------ -----------------
>>>>>>>>>>>> ----------------
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>> --- --- ---------
>>>>>>>>>>>>>>> AYOVHV+Facit-Bold Type 1C Custom
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 131 0
>>>>>>>>>>>>>>> AYOVHV+ProximaNova-Bold Type 1C Custom
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 132 0
>>>>>>>>>>>>>>> AYOVHV+ProximaNova-Light Type 1C Custom
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 133 0
>>>>>>>>>>>>>>> AYOVHV+ProximaNova-Semibold Type 1C
>>> WinAnsi
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 134 0
>>>>>>>>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> no no 9 0
>>>>>>>>>>>>>>> AYOVHV+ProximaNova-Light Type 1C
>>> WinAnsi
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes no 192 0
>>>>>>>>>>>>>>> AYOVHV+ProximaNova-Light Type 1C
>>> WinAnsi
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes no 193 0
>>>>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 275 0
>>>>>>>>>>>>>>> *MHGLSX+ProximaNova-Regular Type 1C
>>> WinAnsi
>>>>>>>>>>>>>>> yes yes yes 276 0*
>>>>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 277 0
>>>>>>>>>>>>>>> MHGLSX+Facit-Bold Type 1C Custom
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 278 0
>>>>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
>>> WinAnsi
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 437 0
>>>>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
>>> WinAnsi
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 438 0
>>>>>>>>>>>>>>> ProximaNova-Bold Type 1C (OT) Custom
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> no no 462 0
>>>>>>>>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> no no 512 0
>>>>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
>>> WinAnsi
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 500 0
>>>>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
>>> WinAnsi
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 501 0
>>>>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
>>> WinAnsi
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 503 0
>>>>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
>>> WinAnsi
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 504 0
>>>>>>>>>>>>>>> FJORTL+ProximaNova-Light CID Type 0C
>>>>> Identity-H
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 377 0
>>>>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
>>> WinAnsi
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 451 0
>>>>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
>>> WinAnsi
>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>> yes yes 452 0
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Why are the field values not showing up and how can I fix
>>> that?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks for your help!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Johannes
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>>>
>>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>
>>>
>>
Re: Weird issue with fonts in input fields after merging
Posted by Johannes Barre <jo...@billfront.com>.
Hello Maruan!
Did you (or anyone else) had the chance to look at my issue? I know, it's
all voluntary work you guys do, so I feel bad keeping bugging you with my
issues. But I think, I'm so close to get everything working, so it would be
a shame to throw this away and try something different...
To summarize the it: I have a PDF, which has on each page an input field
named page_num. I want to fill in the page number of the current page. You
suggested:
For that to work each page_num field has to be an individual field as
otherwise they do share the same value. What you could do, if you need to
make the field a set of individual ones is to (roughly)
- iterate the PDAnnotationWidgets
- get the COSDictionary
- create a new PDField with the COSDictionary and the original field as
parent
- set an individual field name
My implementation, which generates unstyled input fields, is here
(including PDFs):
https://gist.github.com/iGEL/a8484f0bc44b03fa9de1#file-test-java (as said
before, I haven't found a way to set the field parent with PDFBox 2.0)
I would like to keep the original style (color + font). Maybe I can
decouple the widgets completely (not leave them as children to the original
field?).
Greets, Johannes
On Thu, Oct 22, 2015 at 10:56 AM, Johannes Barre <
johannes.barre@billfront.com> wrote:
> Hello!
>
> Sorry for the late reply, I had to do different tasks. But finally I've
> got back to this. The form now looks great, thank you for that!
>
> However, remember the solution for the page numbering you gave me here?
> https://issues.apache.org/jira/browse/PDFBOX-2980?focusedCommentId=14900931&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14900931
>
> That still works, but the numbers are showing up in black (the font
> doesn't look right as well). I tried to find the issue, but to me it looks
> fine. Maybe I did something wrong? Or maybe the coloring thingy doesn't
> work for child fields?
>
> In 1.8.10, PDField used to have a setParent() method, but it disappeared
> in 2.0.0. I haven't found an alternative, so I don't set the parent. Could
> that cause the problem?
>
> I translated my strategy into (crappy) Java for easier debugging, please
> find it here (together with the source and generated PDF):
> https://gist.github.com/iGEL/a8484f0bc44b03fa9de1#file-test-java
>
> Greets, Johannes
>
> On Thu, Oct 15, 2015 at 1:34 AM, Maruan Sahyoun <sa...@fileaffairs.de>
> wrote:
>
>> Hi Kevin,
>> > Am 14.10.2015 um 12:05 schrieb Johannes Barre <
>> johannes.barre@billfront.com>:
>> >
>> > Cool, thank you! :)
>> >
>>
>> I've committed support for text color - please give it a try: If there
>> are issues please add your comments to
>>
>> https://issues.apache.org/jira/browse/PDFBOX-3023
>>
>> BR
>> Maruan
>>
>> > On Wed, Oct 14, 2015 at 12:03 PM, Maruan Sahyoun <
>> sahyoun@fileaffairs.de>
>> > wrote:
>> >
>> >> Hi Johannes,
>> >>
>> >>
>> >>> Am 14.10.2015 um 11:51 schrieb Johannes Barre <
>> >> johannes.barre@billfront.com>:
>> >>>
>> >>> Hello Maruan!
>> >>>
>> >>> Thank you for your help. I ported my real app to use the
>> >>> pdfbox-app-2.0.0-20151010.170237-1722.jar snapshot. The fields are
>> filled
>> >>> correctly and show up in all programs I tried.
>> >>>
>> >>> However, somehow the text color in the fields is black. I spend quite
>> >> some
>> >>> time investigating why, but my knowledge of PDF internals is just too
>> >>> limited. The text fields have a DA value of "/ProximaNova-Regular 9 Tf
>> >>> 0.019 0.305 0.627 rg", and I assume, these three numbers are the RGB
>> >> values
>> >>> on a scale from 0 to 1. That would give me the color #054ea1, which is
>> >>> correct. So why is it showing up in black? When focus the field in
>> >>> AcrobatReader, it changes to the correct blue, so probably some other
>> >> value
>> >>> is responsible for the non-focused color. I wasn't able to figure out,
>> >>> which.
>> >>>
>> >>
>> >> the reason is unfortunately very simple - the color setting in the DA
>> >> string is not (yet) respected when creating the appearance stream i.e.
>> the
>> >> visual presentation of the field.
>> >>
>> >> I've created https://issues.apache.org/jira/browse/PDFBOX-3023 for
>> that.
>> >>
>> >> BR
>> >> Maruan
>> >>
>> >>
>> >>> Greets, Johannes
>> >>>
>> >>> On Fri, Oct 9, 2015 at 8:05 PM, Maruan Sahyoun <
>> sahyoun@fileaffairs.de>
>> >>> wrote:
>> >>>
>> >>>> Hi,
>> >>>>
>> >>>>> Am 09.10.2015 um 18:28 schrieb Johannes Barre <
>> >>>> johannes.barre@billfront.com>:
>> >>>>>
>> >>>>> Hello Maruan!
>> >>>>>
>> >>>>> I don't want to push you, but even if you couldn't figure out
>> >> everything,
>> >>>>> also intermediate results or even just ideas could be helpful.
>> >>>>>
>> >>>>> I experimented a bit more and found, that setValue sometimes works
>> with
>> >>>>> umlauts and sometimes doesn't when I use setValue instead of my
>> hack.
>> >> So,
>> >>>>> with the BIW_FORM.pdf, they are scrambled, but with the
>> umlauts_ok.pdf,
>> >>>>> they are fine. Any idea, why they are scrambled in the BIW_FORM.pdf?
>> >> Do I
>> >>>>> need to convert the character encoding? How do I detect which
>> encoding
>> >> is
>> >>>>> required?
>> >>>>>
>> >>>>
>> >>>> the 1.8 (and previous) version were not really dealing correctly with
>> >>>> character encodings specially if the font is subset. 2.0 does that
>> >>>> correctly. I did a quick hack to support encode() for Type 1 C fonts
>> and
>> >>>> after that your form works fine even with the umlaut.
>> >>>>
>> >>>> I've created https://issues.apache.org/jira/browse/PDFBOX-3016 <
>> >>>> https://issues.apache.org/jira/browse/PDFBOX-3016> for that.
>> >>>>
>> >>>> BR
>> >>>> Maruan
>> >>>>
>> >>>>> If I could fix this issue, I probably could use setValue. When using
>> >>>>> setValue, the values show up in Acrobat Reader even when I merge the
>> >>>>> documents :D
>> >>>>>
>> >>>>> Greets, Johannes
>> >>>>>
>> >>>>> On Thu, Oct 8, 2015 at 4:35 PM, Maruan Sahyoun <
>> sahyoun@fileaffairs.de
>> >>>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> Hi,
>> >>>>>>
>> >>>>>>> Am 08.10.2015 um 16:31 schrieb Johannes Barre <
>> >>>>>> johannes.barre@billfront.com>:
>> >>>>>>>
>> >>>>>>> Hello!
>> >>>>>>>
>> >>>>>>> I just tried the 2.0 snapshot from yesterday and get this error:
>> >>>>>>>
>> >>>>>>> org/apache/pdfbox/pdmodel/font/PDType1CFont.java:283:in `encode':
>> >>>>>>> java.lang.UnsupportedOperationException: Not implemented: Type1C
>> >>>>>>
>> >>>>>> there is already a ticket for that.
>> >>>>>>
>> >>>>>> BR Maruan
>> >>>>>>
>> >>>>>>>
>> >>>>>>> Is that also true for 1.8.10 (just without the error) and could
>> it be
>> >>>>>>> related to the problem?
>> >>>>>>>
>> >>>>>>> Greets, Johannes
>> >>>>>>>
>> >>>>>>> PS: I've also pushed a Java version of my code to the gist. It's
>> >>>> probably
>> >>>>>>> as messy as my JRuby version, they're just experiments.
>> >>>>>>>
>> >>>>>>> On Thu, Oct 8, 2015 at 3:41 PM, Johannes Barre <
>> >>>>>> johannes.barre@billfront.com
>> >>>>>>>> wrote:
>> >>>>>>>
>> >>>>>>>> Hello Maruan!
>> >>>>>>>>
>> >>>>>>>> Thank again. I hope my last answer didn't sounded too aggressive
>> >>>>>> (written
>> >>>>>>>> communication is difficult). I'm grateful for any help!
>> >>>>>>>>
>> >>>>>>>> You brought up a good point, as a Linux user I've only checked
>> with
>> >>>>>> Google
>> >>>>>>>> Chrome & xpdf (and I was referring to the xpdf). In the Acrobat
>> >>>> Reader 9
>> >>>>>>>> (Linux) and XI (Win XP), the field values are not shown. So I
>> got a
>> >>>> new
>> >>>>>>>> problem :'(
>> >>>>>>>>
>> >>>>>>>> Greets, Johannes
>> >>>>>>>>
>> >>>>>>>> On Thu, Oct 8, 2015 at 3:00 PM, Maruan Sahyoun <
>> >>>> sahyoun@fileaffairs.de>
>> >>>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>>> Hi,
>> >>>>>>>>>
>> >>>>>>>>>>> Am 08.10.2015 um 14:53 schrieb Johannes Barre <
>> >>>>>>>>>> johannes.barre@billfront.com>:
>> >>>>>>>>>>
>> >>>>>>>>>> Hello Maruan!
>> >>>>>>>>>>
>> >>>>>>>>>> Thank you for your reply.
>> >>>>>>>>>>
>> >>>>>>>>>> So, basically you say, the source PDFs aren't valid already?
>> I've
>> >>>>>> asked
>> >>>>>>>>> and
>> >>>>>>>>>> they were created with Adobe InDesign, I would hope that Adobe
>> >> knows
>> >>>>>>>>> how to
>> >>>>>>>>>> generate valid PDFs. :-/
>> >>>>>>>>>
>> >>>>>>>>> the PDFs are not invalid - that's not what I wanted to say.
>> >>>>>>>>>
>> >>>>>>>>>> But even so, why is everything looking good when I just fill in
>> >> the
>> >>>>>>>>> fields
>> >>>>>>>>>> without merging it? It has the same issue with the fonts name
>> and
>> >> I
>> >>>>>>>>> filled
>> >>>>>>>>>> the field with the same method.
>> >>>>>>>>>
>> >>>>>>>>> when you say looking good - are you looking at it with Adobe
>> Reader
>> >>>> or
>> >>>>>>>>> XPDF or ….
>> >>>>>>>>>
>> >>>>>>>>> I can have a more in-depth look tonight - my comments were about
>> >> the
>> >>>>>>>>> quick observations I made.
>> >>>>>>>>>
>> >>>>>>>>> BR
>> >>>>>>>>> Maruan
>> >>>>>>>>>
>> >>>>>>>>>> Greets, Johannes
>> >>>>>>>>>>
>> >>>>>>>>>> On Thu, Oct 8, 2015 at 2:35 PM, Maruan Sahyoun <
>> >>>>>> sahyoun@fileaffairs.de>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> Hi,
>> >>>>>>>>>>>
>> >>>>>>>>>>>>> Am 08.10.2015 um 13:30 schrieb Johannes Barre <
>> >>>>>>>>>>>> johannes.barre@billfront.com>:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Hello!
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> I have a weird issue. So, I have to PDFs. When I fill form
>> >> fields
>> >>>> in
>> >>>>>>>>> one
>> >>>>>>>>>>> of
>> >>>>>>>>>>>> them and save, everything looks fine. However, when I append
>> >> this
>> >>>>>>>>> filled
>> >>>>>>>>>>>> PDF to another one, xpdf doesn't display the values anymore
>> and
>> >>>>>>>>> complains
>> >>>>>>>>>>>> about missing fonts:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
>> >>>>>>>>>>>> Syntax Error: Unknown font in field's DA string
>> >>>>>>>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
>> >>>>>>>>>>>> Syntax Error: Unknown font in field's DA string
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> I'm using JRuby (9k), but I hope it's understandable for
>> you. I
>> >>>> put
>> >>>>>>>>> the
>> >>>>>>>>>>>> source & PDFs in this gist:
>> >>>>>>>>>>>> https://gist.github.com/iGEL/a8484f0bc44b03fa9de1 (Will
>> delete
>> >> it
>> >>>>>>>>> later,
>> >>>>>>>>>>>> once the issue is solved)
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Other specs: pdfbox-app-1.8.10, openjdk 1.8.0_66, Debian
>> Jessy
>> >>>>>> inside
>> >>>>>>>>> of
>> >>>>>>>>>>>> Docker
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> As you can see, I use a special way to set the values. I had
>> >>>>>> problems
>> >>>>>>>>>>> with
>> >>>>>>>>>>>> German umlauts using setValue and it also sometimes fails
>> >>>> (Possibly
>> >>>>>>>>>>> related
>> >>>>>>>>>>>> to https://issues.apache.org/jira/browse/PDFBOX-1550, the
>> >> message
>> >>>>>> is
>> >>>>>>>>> the
>> >>>>>>>>>>>> same as in that bug)
>> >>>>>>>>>>>
>> >>>>>>>>>>> setting the field value directly using
>> >>>>>>>>>>>
>> >>>>>>>>>>> form.getField(name).getDictionary.setItem(
>> >>>>>>>>>>> Java::OrgApachePdfboxCos::COSName::V,
>> >>>>>>>>>>> Java::OrgApachePdfboxCos::COSString.new(value)
>> >>>>>>>>>>> )
>> >>>>>>>>>>>
>> >>>>>>>>>>> will not update the visual appearance of the filed and as a
>> >> result
>> >>>>>> the
>> >>>>>>>>>>> newly set value is not visible
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>> The COVER_PAGE.pdf and BIW_FORM.pdf are the templates I'm
>> using,
>> >>>>>>>>>>>> form_filled.pdf is just the BIW_FORM.pdf with 2 fields filled
>> >> and
>> >>>>>>>>> merged
>> >>>>>>>>>>> is
>> >>>>>>>>>>>> COVER_PAGE.pdf and form_filled.pdf merged together.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> The p in line 15 and 22 print out the DA value of the field
>> and
>> >>>> it's
>> >>>>>>>>> the
>> >>>>>>>>>>>> same for both files:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" #
>> >> form_filled.pdf
>> >>>>>>>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # merged.pdf
>> >>>>>>>>>>>
>> >>>>>>>>>>> the font resource is called /ProximaNova-Regular but that's
>> not
>> >> in
>> >>>>>> your
>> >>>>>>>>>>> PDF as the font which is in your PDF is called
>> >>>>>>>>> /MHGLSX+ProximaNova-Regular.
>> >>>>>>>>>>> In addition the issue with a font subset is that only certain
>> >>>>>>>>> characters
>> >>>>>>>>>>> are part of that subset. As a result some of the characters
>> you
>> >>>> need
>> >>>>>> to
>> >>>>>>>>>>> display your field value might not be within the subset.
>> >>>>>>>>>>>
>> >>>>>>>>>>> BR
>> >>>>>>>>>>> Maruan
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> This font is according to pdffonts in both files:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> $ pdffonts form_filled.pdf
>> >>>>>>>>>>>> name type
>> encoding
>> >>>>>>>>>>> emb
>> >>>>>>>>>>>> sub uni object ID
>> >>>>>>>>>>>> ------------------------------------ -----------------
>> >>>>>>>>> ----------------
>> >>>>>>>>>>> ---
>> >>>>>>>>>>>> --- --- ---------
>> >>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 124 0
>> >>>>>>>>>>>> *MHGLSX+ProximaNova-Regular Type 1C
>> WinAnsi
>> >>>>>>>>>>>> yes yes yes 125 0*
>> >>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 126 0
>> >>>>>>>>>>>> MHGLSX+Facit-Bold Type 1C Custom
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 127 0
>> >>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
>> WinAnsi
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 218 0
>> >>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
>> WinAnsi
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 219 0
>> >>>>>>>>>>>> ProximaNova-Bold Type 1C (OT) Custom
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> no no 8 0
>> >>>>>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> no no 9 0
>> >>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
>> WinAnsi
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 251 0
>> >>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
>> WinAnsi
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 252 0
>> >>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
>> WinAnsi
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 254 0
>> >>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
>> WinAnsi
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 255 0
>> >>>>>>>>>>>> FJORTL+ProximaNova-Light CID Type 0C
>> >> Identity-H
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 165 0
>> >>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
>> WinAnsi
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 259 0
>> >>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
>> WinAnsi
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 260 0
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> $pdffonts merged.pdf
>> >>>>>>>>>>>> name type
>> encoding
>> >>>>>>>>>>> emb
>> >>>>>>>>>>>> sub uni object ID
>> >>>>>>>>>>>> ------------------------------------ -----------------
>> >>>>>>>>> ----------------
>> >>>>>>>>>>> ---
>> >>>>>>>>>>>> --- --- ---------
>> >>>>>>>>>>>> AYOVHV+Facit-Bold Type 1C Custom
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 131 0
>> >>>>>>>>>>>> AYOVHV+ProximaNova-Bold Type 1C Custom
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 132 0
>> >>>>>>>>>>>> AYOVHV+ProximaNova-Light Type 1C Custom
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 133 0
>> >>>>>>>>>>>> AYOVHV+ProximaNova-Semibold Type 1C
>> WinAnsi
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 134 0
>> >>>>>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> no no 9 0
>> >>>>>>>>>>>> AYOVHV+ProximaNova-Light Type 1C
>> WinAnsi
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes no 192 0
>> >>>>>>>>>>>> AYOVHV+ProximaNova-Light Type 1C
>> WinAnsi
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes no 193 0
>> >>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 275 0
>> >>>>>>>>>>>> *MHGLSX+ProximaNova-Regular Type 1C
>> WinAnsi
>> >>>>>>>>>>>> yes yes yes 276 0*
>> >>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 277 0
>> >>>>>>>>>>>> MHGLSX+Facit-Bold Type 1C Custom
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 278 0
>> >>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
>> WinAnsi
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 437 0
>> >>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
>> WinAnsi
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 438 0
>> >>>>>>>>>>>> ProximaNova-Bold Type 1C (OT) Custom
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> no no 462 0
>> >>>>>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> no no 512 0
>> >>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
>> WinAnsi
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 500 0
>> >>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
>> WinAnsi
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 501 0
>> >>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
>> WinAnsi
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 503 0
>> >>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
>> WinAnsi
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 504 0
>> >>>>>>>>>>>> FJORTL+ProximaNova-Light CID Type 0C
>> >> Identity-H
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 377 0
>> >>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C
>> WinAnsi
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 451 0
>> >>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C
>> WinAnsi
>> >>>>>>>>>>> yes
>> >>>>>>>>>>>> yes yes 452 0
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Why are the field values not showing up and how can I fix
>> that?
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Thanks for your help!
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Johannes
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>> ---------------------------------------------------------------------
>> >>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> >>>>>>>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >> ---------------------------------------------------------------------
>> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> >>>>>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>> >>>>>>>>
>> >>>>>>
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> >>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>>>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> >> For additional commands, e-mail: users-help@pdfbox.apache.org
>> >>
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>>
>
Re: Weird issue with fonts in input fields after merging
Posted by Johannes Barre <jo...@billfront.com>.
Hello!
Sorry for the late reply, I had to do different tasks. But finally I've got
back to this. The form now looks great, thank you for that!
However, remember the solution for the page numbering you gave me here?
https://issues.apache.org/jira/browse/PDFBOX-2980?focusedCommentId=14900931&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14900931
That still works, but the numbers are showing up in black (the font doesn't
look right as well). I tried to find the issue, but to me it looks fine.
Maybe I did something wrong? Or maybe the coloring thingy doesn't work for
child fields?
In 1.8.10, PDField used to have a setParent() method, but it disappeared in
2.0.0. I haven't found an alternative, so I don't set the parent. Could
that cause the problem?
I translated my strategy into (crappy) Java for easier debugging, please
find it here (together with the source and generated PDF):
https://gist.github.com/iGEL/a8484f0bc44b03fa9de1#file-test-java
Greets, Johannes
On Thu, Oct 15, 2015 at 1:34 AM, Maruan Sahyoun <sa...@fileaffairs.de>
wrote:
> Hi Kevin,
> > Am 14.10.2015 um 12:05 schrieb Johannes Barre <
> johannes.barre@billfront.com>:
> >
> > Cool, thank you! :)
> >
>
> I've committed support for text color - please give it a try: If there are
> issues please add your comments to
>
> https://issues.apache.org/jira/browse/PDFBOX-3023
>
> BR
> Maruan
>
> > On Wed, Oct 14, 2015 at 12:03 PM, Maruan Sahyoun <sahyoun@fileaffairs.de
> >
> > wrote:
> >
> >> Hi Johannes,
> >>
> >>
> >>> Am 14.10.2015 um 11:51 schrieb Johannes Barre <
> >> johannes.barre@billfront.com>:
> >>>
> >>> Hello Maruan!
> >>>
> >>> Thank you for your help. I ported my real app to use the
> >>> pdfbox-app-2.0.0-20151010.170237-1722.jar snapshot. The fields are
> filled
> >>> correctly and show up in all programs I tried.
> >>>
> >>> However, somehow the text color in the fields is black. I spend quite
> >> some
> >>> time investigating why, but my knowledge of PDF internals is just too
> >>> limited. The text fields have a DA value of "/ProximaNova-Regular 9 Tf
> >>> 0.019 0.305 0.627 rg", and I assume, these three numbers are the RGB
> >> values
> >>> on a scale from 0 to 1. That would give me the color #054ea1, which is
> >>> correct. So why is it showing up in black? When focus the field in
> >>> AcrobatReader, it changes to the correct blue, so probably some other
> >> value
> >>> is responsible for the non-focused color. I wasn't able to figure out,
> >>> which.
> >>>
> >>
> >> the reason is unfortunately very simple - the color setting in the DA
> >> string is not (yet) respected when creating the appearance stream i.e.
> the
> >> visual presentation of the field.
> >>
> >> I've created https://issues.apache.org/jira/browse/PDFBOX-3023 for
> that.
> >>
> >> BR
> >> Maruan
> >>
> >>
> >>> Greets, Johannes
> >>>
> >>> On Fri, Oct 9, 2015 at 8:05 PM, Maruan Sahyoun <sahyoun@fileaffairs.de
> >
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>>> Am 09.10.2015 um 18:28 schrieb Johannes Barre <
> >>>> johannes.barre@billfront.com>:
> >>>>>
> >>>>> Hello Maruan!
> >>>>>
> >>>>> I don't want to push you, but even if you couldn't figure out
> >> everything,
> >>>>> also intermediate results or even just ideas could be helpful.
> >>>>>
> >>>>> I experimented a bit more and found, that setValue sometimes works
> with
> >>>>> umlauts and sometimes doesn't when I use setValue instead of my hack.
> >> So,
> >>>>> with the BIW_FORM.pdf, they are scrambled, but with the
> umlauts_ok.pdf,
> >>>>> they are fine. Any idea, why they are scrambled in the BIW_FORM.pdf?
> >> Do I
> >>>>> need to convert the character encoding? How do I detect which
> encoding
> >> is
> >>>>> required?
> >>>>>
> >>>>
> >>>> the 1.8 (and previous) version were not really dealing correctly with
> >>>> character encodings specially if the font is subset. 2.0 does that
> >>>> correctly. I did a quick hack to support encode() for Type 1 C fonts
> and
> >>>> after that your form works fine even with the umlaut.
> >>>>
> >>>> I've created https://issues.apache.org/jira/browse/PDFBOX-3016 <
> >>>> https://issues.apache.org/jira/browse/PDFBOX-3016> for that.
> >>>>
> >>>> BR
> >>>> Maruan
> >>>>
> >>>>> If I could fix this issue, I probably could use setValue. When using
> >>>>> setValue, the values show up in Acrobat Reader even when I merge the
> >>>>> documents :D
> >>>>>
> >>>>> Greets, Johannes
> >>>>>
> >>>>> On Thu, Oct 8, 2015 at 4:35 PM, Maruan Sahyoun <
> sahyoun@fileaffairs.de
> >>>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>>> Am 08.10.2015 um 16:31 schrieb Johannes Barre <
> >>>>>> johannes.barre@billfront.com>:
> >>>>>>>
> >>>>>>> Hello!
> >>>>>>>
> >>>>>>> I just tried the 2.0 snapshot from yesterday and get this error:
> >>>>>>>
> >>>>>>> org/apache/pdfbox/pdmodel/font/PDType1CFont.java:283:in `encode':
> >>>>>>> java.lang.UnsupportedOperationException: Not implemented: Type1C
> >>>>>>
> >>>>>> there is already a ticket for that.
> >>>>>>
> >>>>>> BR Maruan
> >>>>>>
> >>>>>>>
> >>>>>>> Is that also true for 1.8.10 (just without the error) and could it
> be
> >>>>>>> related to the problem?
> >>>>>>>
> >>>>>>> Greets, Johannes
> >>>>>>>
> >>>>>>> PS: I've also pushed a Java version of my code to the gist. It's
> >>>> probably
> >>>>>>> as messy as my JRuby version, they're just experiments.
> >>>>>>>
> >>>>>>> On Thu, Oct 8, 2015 at 3:41 PM, Johannes Barre <
> >>>>>> johannes.barre@billfront.com
> >>>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hello Maruan!
> >>>>>>>>
> >>>>>>>> Thank again. I hope my last answer didn't sounded too aggressive
> >>>>>> (written
> >>>>>>>> communication is difficult). I'm grateful for any help!
> >>>>>>>>
> >>>>>>>> You brought up a good point, as a Linux user I've only checked
> with
> >>>>>> Google
> >>>>>>>> Chrome & xpdf (and I was referring to the xpdf). In the Acrobat
> >>>> Reader 9
> >>>>>>>> (Linux) and XI (Win XP), the field values are not shown. So I got
> a
> >>>> new
> >>>>>>>> problem :'(
> >>>>>>>>
> >>>>>>>> Greets, Johannes
> >>>>>>>>
> >>>>>>>> On Thu, Oct 8, 2015 at 3:00 PM, Maruan Sahyoun <
> >>>> sahyoun@fileaffairs.de>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>>>> Am 08.10.2015 um 14:53 schrieb Johannes Barre <
> >>>>>>>>>> johannes.barre@billfront.com>:
> >>>>>>>>>>
> >>>>>>>>>> Hello Maruan!
> >>>>>>>>>>
> >>>>>>>>>> Thank you for your reply.
> >>>>>>>>>>
> >>>>>>>>>> So, basically you say, the source PDFs aren't valid already?
> I've
> >>>>>> asked
> >>>>>>>>> and
> >>>>>>>>>> they were created with Adobe InDesign, I would hope that Adobe
> >> knows
> >>>>>>>>> how to
> >>>>>>>>>> generate valid PDFs. :-/
> >>>>>>>>>
> >>>>>>>>> the PDFs are not invalid - that's not what I wanted to say.
> >>>>>>>>>
> >>>>>>>>>> But even so, why is everything looking good when I just fill in
> >> the
> >>>>>>>>> fields
> >>>>>>>>>> without merging it? It has the same issue with the fonts name
> and
> >> I
> >>>>>>>>> filled
> >>>>>>>>>> the field with the same method.
> >>>>>>>>>
> >>>>>>>>> when you say looking good - are you looking at it with Adobe
> Reader
> >>>> or
> >>>>>>>>> XPDF or ….
> >>>>>>>>>
> >>>>>>>>> I can have a more in-depth look tonight - my comments were about
> >> the
> >>>>>>>>> quick observations I made.
> >>>>>>>>>
> >>>>>>>>> BR
> >>>>>>>>> Maruan
> >>>>>>>>>
> >>>>>>>>>> Greets, Johannes
> >>>>>>>>>>
> >>>>>>>>>> On Thu, Oct 8, 2015 at 2:35 PM, Maruan Sahyoun <
> >>>>>> sahyoun@fileaffairs.de>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hi,
> >>>>>>>>>>>
> >>>>>>>>>>>>> Am 08.10.2015 um 13:30 schrieb Johannes Barre <
> >>>>>>>>>>>> johannes.barre@billfront.com>:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hello!
> >>>>>>>>>>>>
> >>>>>>>>>>>> I have a weird issue. So, I have to PDFs. When I fill form
> >> fields
> >>>> in
> >>>>>>>>> one
> >>>>>>>>>>> of
> >>>>>>>>>>>> them and save, everything looks fine. However, when I append
> >> this
> >>>>>>>>> filled
> >>>>>>>>>>>> PDF to another one, xpdf doesn't display the values anymore
> and
> >>>>>>>>> complains
> >>>>>>>>>>>> about missing fonts:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
> >>>>>>>>>>>> Syntax Error: Unknown font in field's DA string
> >>>>>>>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
> >>>>>>>>>>>> Syntax Error: Unknown font in field's DA string
> >>>>>>>>>>>>
> >>>>>>>>>>>> I'm using JRuby (9k), but I hope it's understandable for you.
> I
> >>>> put
> >>>>>>>>> the
> >>>>>>>>>>>> source & PDFs in this gist:
> >>>>>>>>>>>> https://gist.github.com/iGEL/a8484f0bc44b03fa9de1 (Will
> delete
> >> it
> >>>>>>>>> later,
> >>>>>>>>>>>> once the issue is solved)
> >>>>>>>>>>>>
> >>>>>>>>>>>> Other specs: pdfbox-app-1.8.10, openjdk 1.8.0_66, Debian Jessy
> >>>>>> inside
> >>>>>>>>> of
> >>>>>>>>>>>> Docker
> >>>>>>>>>>>>
> >>>>>>>>>>>> As you can see, I use a special way to set the values. I had
> >>>>>> problems
> >>>>>>>>>>> with
> >>>>>>>>>>>> German umlauts using setValue and it also sometimes fails
> >>>> (Possibly
> >>>>>>>>>>> related
> >>>>>>>>>>>> to https://issues.apache.org/jira/browse/PDFBOX-1550, the
> >> message
> >>>>>> is
> >>>>>>>>> the
> >>>>>>>>>>>> same as in that bug)
> >>>>>>>>>>>
> >>>>>>>>>>> setting the field value directly using
> >>>>>>>>>>>
> >>>>>>>>>>> form.getField(name).getDictionary.setItem(
> >>>>>>>>>>> Java::OrgApachePdfboxCos::COSName::V,
> >>>>>>>>>>> Java::OrgApachePdfboxCos::COSString.new(value)
> >>>>>>>>>>> )
> >>>>>>>>>>>
> >>>>>>>>>>> will not update the visual appearance of the filed and as a
> >> result
> >>>>>> the
> >>>>>>>>>>> newly set value is not visible
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> The COVER_PAGE.pdf and BIW_FORM.pdf are the templates I'm
> using,
> >>>>>>>>>>>> form_filled.pdf is just the BIW_FORM.pdf with 2 fields filled
> >> and
> >>>>>>>>> merged
> >>>>>>>>>>> is
> >>>>>>>>>>>> COVER_PAGE.pdf and form_filled.pdf merged together.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The p in line 15 and 22 print out the DA value of the field
> and
> >>>> it's
> >>>>>>>>> the
> >>>>>>>>>>>> same for both files:
> >>>>>>>>>>>>
> >>>>>>>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" #
> >> form_filled.pdf
> >>>>>>>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # merged.pdf
> >>>>>>>>>>>
> >>>>>>>>>>> the font resource is called /ProximaNova-Regular but that's not
> >> in
> >>>>>> your
> >>>>>>>>>>> PDF as the font which is in your PDF is called
> >>>>>>>>> /MHGLSX+ProximaNova-Regular.
> >>>>>>>>>>> In addition the issue with a font subset is that only certain
> >>>>>>>>> characters
> >>>>>>>>>>> are part of that subset. As a result some of the characters you
> >>>> need
> >>>>>> to
> >>>>>>>>>>> display your field value might not be within the subset.
> >>>>>>>>>>>
> >>>>>>>>>>> BR
> >>>>>>>>>>> Maruan
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> This font is according to pdffonts in both files:
> >>>>>>>>>>>>
> >>>>>>>>>>>> $ pdffonts form_filled.pdf
> >>>>>>>>>>>> name type
> encoding
> >>>>>>>>>>> emb
> >>>>>>>>>>>> sub uni object ID
> >>>>>>>>>>>> ------------------------------------ -----------------
> >>>>>>>>> ----------------
> >>>>>>>>>>> ---
> >>>>>>>>>>>> --- --- ---------
> >>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 124 0
> >>>>>>>>>>>> *MHGLSX+ProximaNova-Regular Type 1C
> WinAnsi
> >>>>>>>>>>>> yes yes yes 125 0*
> >>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 126 0
> >>>>>>>>>>>> MHGLSX+Facit-Bold Type 1C Custom
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 127 0
> >>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 218 0
> >>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 219 0
> >>>>>>>>>>>> ProximaNova-Bold Type 1C (OT) Custom
> >>>>>>>>>>> yes
> >>>>>>>>>>>> no no 8 0
> >>>>>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
> >>>>>>>>>>> yes
> >>>>>>>>>>>> no no 9 0
> >>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 251 0
> >>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 252 0
> >>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 254 0
> >>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 255 0
> >>>>>>>>>>>> FJORTL+ProximaNova-Light CID Type 0C
> >> Identity-H
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 165 0
> >>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 259 0
> >>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 260 0
> >>>>>>>>>>>>
> >>>>>>>>>>>> $pdffonts merged.pdf
> >>>>>>>>>>>> name type
> encoding
> >>>>>>>>>>> emb
> >>>>>>>>>>>> sub uni object ID
> >>>>>>>>>>>> ------------------------------------ -----------------
> >>>>>>>>> ----------------
> >>>>>>>>>>> ---
> >>>>>>>>>>>> --- --- ---------
> >>>>>>>>>>>> AYOVHV+Facit-Bold Type 1C Custom
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 131 0
> >>>>>>>>>>>> AYOVHV+ProximaNova-Bold Type 1C Custom
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 132 0
> >>>>>>>>>>>> AYOVHV+ProximaNova-Light Type 1C Custom
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 133 0
> >>>>>>>>>>>> AYOVHV+ProximaNova-Semibold Type 1C WinAnsi
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 134 0
> >>>>>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
> >>>>>>>>>>> yes
> >>>>>>>>>>>> no no 9 0
> >>>>>>>>>>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes no 192 0
> >>>>>>>>>>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes no 193 0
> >>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 275 0
> >>>>>>>>>>>> *MHGLSX+ProximaNova-Regular Type 1C
> WinAnsi
> >>>>>>>>>>>> yes yes yes 276 0*
> >>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 277 0
> >>>>>>>>>>>> MHGLSX+Facit-Bold Type 1C Custom
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 278 0
> >>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 437 0
> >>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 438 0
> >>>>>>>>>>>> ProximaNova-Bold Type 1C (OT) Custom
> >>>>>>>>>>> yes
> >>>>>>>>>>>> no no 462 0
> >>>>>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
> >>>>>>>>>>> yes
> >>>>>>>>>>>> no no 512 0
> >>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 500 0
> >>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 501 0
> >>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 503 0
> >>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 504 0
> >>>>>>>>>>>> FJORTL+ProximaNova-Light CID Type 0C
> >> Identity-H
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 377 0
> >>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 451 0
> >>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>>>>>> yes
> >>>>>>>>>>>> yes yes 452 0
> >>>>>>>>>>>>
> >>>>>>>>>>>> Why are the field values not showing up and how can I fix
> that?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks for your help!
> >>>>>>>>>>>>
> >>>>>>>>>>>> Johannes
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> >>>>>>>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> >>>>>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>>>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> >>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> >> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
>
Re: Weird issue with fonts in input fields after merging
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi Kevin,
> Am 14.10.2015 um 12:05 schrieb Johannes Barre <jo...@billfront.com>:
>
> Cool, thank you! :)
>
I've committed support for text color - please give it a try: If there are issues please add your comments to
https://issues.apache.org/jira/browse/PDFBOX-3023
BR
Maruan
> On Wed, Oct 14, 2015 at 12:03 PM, Maruan Sahyoun <sa...@fileaffairs.de>
> wrote:
>
>> Hi Johannes,
>>
>>
>>> Am 14.10.2015 um 11:51 schrieb Johannes Barre <
>> johannes.barre@billfront.com>:
>>>
>>> Hello Maruan!
>>>
>>> Thank you for your help. I ported my real app to use the
>>> pdfbox-app-2.0.0-20151010.170237-1722.jar snapshot. The fields are filled
>>> correctly and show up in all programs I tried.
>>>
>>> However, somehow the text color in the fields is black. I spend quite
>> some
>>> time investigating why, but my knowledge of PDF internals is just too
>>> limited. The text fields have a DA value of "/ProximaNova-Regular 9 Tf
>>> 0.019 0.305 0.627 rg", and I assume, these three numbers are the RGB
>> values
>>> on a scale from 0 to 1. That would give me the color #054ea1, which is
>>> correct. So why is it showing up in black? When focus the field in
>>> AcrobatReader, it changes to the correct blue, so probably some other
>> value
>>> is responsible for the non-focused color. I wasn't able to figure out,
>>> which.
>>>
>>
>> the reason is unfortunately very simple - the color setting in the DA
>> string is not (yet) respected when creating the appearance stream i.e. the
>> visual presentation of the field.
>>
>> I've created https://issues.apache.org/jira/browse/PDFBOX-3023 for that.
>>
>> BR
>> Maruan
>>
>>
>>> Greets, Johannes
>>>
>>> On Fri, Oct 9, 2015 at 8:05 PM, Maruan Sahyoun <sa...@fileaffairs.de>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>>> Am 09.10.2015 um 18:28 schrieb Johannes Barre <
>>>> johannes.barre@billfront.com>:
>>>>>
>>>>> Hello Maruan!
>>>>>
>>>>> I don't want to push you, but even if you couldn't figure out
>> everything,
>>>>> also intermediate results or even just ideas could be helpful.
>>>>>
>>>>> I experimented a bit more and found, that setValue sometimes works with
>>>>> umlauts and sometimes doesn't when I use setValue instead of my hack.
>> So,
>>>>> with the BIW_FORM.pdf, they are scrambled, but with the umlauts_ok.pdf,
>>>>> they are fine. Any idea, why they are scrambled in the BIW_FORM.pdf?
>> Do I
>>>>> need to convert the character encoding? How do I detect which encoding
>> is
>>>>> required?
>>>>>
>>>>
>>>> the 1.8 (and previous) version were not really dealing correctly with
>>>> character encodings specially if the font is subset. 2.0 does that
>>>> correctly. I did a quick hack to support encode() for Type 1 C fonts and
>>>> after that your form works fine even with the umlaut.
>>>>
>>>> I've created https://issues.apache.org/jira/browse/PDFBOX-3016 <
>>>> https://issues.apache.org/jira/browse/PDFBOX-3016> for that.
>>>>
>>>> BR
>>>> Maruan
>>>>
>>>>> If I could fix this issue, I probably could use setValue. When using
>>>>> setValue, the values show up in Acrobat Reader even when I merge the
>>>>> documents :D
>>>>>
>>>>> Greets, Johannes
>>>>>
>>>>> On Thu, Oct 8, 2015 at 4:35 PM, Maruan Sahyoun <sahyoun@fileaffairs.de
>>>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>> Am 08.10.2015 um 16:31 schrieb Johannes Barre <
>>>>>> johannes.barre@billfront.com>:
>>>>>>>
>>>>>>> Hello!
>>>>>>>
>>>>>>> I just tried the 2.0 snapshot from yesterday and get this error:
>>>>>>>
>>>>>>> org/apache/pdfbox/pdmodel/font/PDType1CFont.java:283:in `encode':
>>>>>>> java.lang.UnsupportedOperationException: Not implemented: Type1C
>>>>>>
>>>>>> there is already a ticket for that.
>>>>>>
>>>>>> BR Maruan
>>>>>>
>>>>>>>
>>>>>>> Is that also true for 1.8.10 (just without the error) and could it be
>>>>>>> related to the problem?
>>>>>>>
>>>>>>> Greets, Johannes
>>>>>>>
>>>>>>> PS: I've also pushed a Java version of my code to the gist. It's
>>>> probably
>>>>>>> as messy as my JRuby version, they're just experiments.
>>>>>>>
>>>>>>> On Thu, Oct 8, 2015 at 3:41 PM, Johannes Barre <
>>>>>> johannes.barre@billfront.com
>>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hello Maruan!
>>>>>>>>
>>>>>>>> Thank again. I hope my last answer didn't sounded too aggressive
>>>>>> (written
>>>>>>>> communication is difficult). I'm grateful for any help!
>>>>>>>>
>>>>>>>> You brought up a good point, as a Linux user I've only checked with
>>>>>> Google
>>>>>>>> Chrome & xpdf (and I was referring to the xpdf). In the Acrobat
>>>> Reader 9
>>>>>>>> (Linux) and XI (Win XP), the field values are not shown. So I got a
>>>> new
>>>>>>>> problem :'(
>>>>>>>>
>>>>>>>> Greets, Johannes
>>>>>>>>
>>>>>>>> On Thu, Oct 8, 2015 at 3:00 PM, Maruan Sahyoun <
>>>> sahyoun@fileaffairs.de>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>>> Am 08.10.2015 um 14:53 schrieb Johannes Barre <
>>>>>>>>>> johannes.barre@billfront.com>:
>>>>>>>>>>
>>>>>>>>>> Hello Maruan!
>>>>>>>>>>
>>>>>>>>>> Thank you for your reply.
>>>>>>>>>>
>>>>>>>>>> So, basically you say, the source PDFs aren't valid already? I've
>>>>>> asked
>>>>>>>>> and
>>>>>>>>>> they were created with Adobe InDesign, I would hope that Adobe
>> knows
>>>>>>>>> how to
>>>>>>>>>> generate valid PDFs. :-/
>>>>>>>>>
>>>>>>>>> the PDFs are not invalid - that's not what I wanted to say.
>>>>>>>>>
>>>>>>>>>> But even so, why is everything looking good when I just fill in
>> the
>>>>>>>>> fields
>>>>>>>>>> without merging it? It has the same issue with the fonts name and
>> I
>>>>>>>>> filled
>>>>>>>>>> the field with the same method.
>>>>>>>>>
>>>>>>>>> when you say looking good - are you looking at it with Adobe Reader
>>>> or
>>>>>>>>> XPDF or ….
>>>>>>>>>
>>>>>>>>> I can have a more in-depth look tonight - my comments were about
>> the
>>>>>>>>> quick observations I made.
>>>>>>>>>
>>>>>>>>> BR
>>>>>>>>> Maruan
>>>>>>>>>
>>>>>>>>>> Greets, Johannes
>>>>>>>>>>
>>>>>>>>>> On Thu, Oct 8, 2015 at 2:35 PM, Maruan Sahyoun <
>>>>>> sahyoun@fileaffairs.de>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>>>> Am 08.10.2015 um 13:30 schrieb Johannes Barre <
>>>>>>>>>>>> johannes.barre@billfront.com>:
>>>>>>>>>>>>
>>>>>>>>>>>> Hello!
>>>>>>>>>>>>
>>>>>>>>>>>> I have a weird issue. So, I have to PDFs. When I fill form
>> fields
>>>> in
>>>>>>>>> one
>>>>>>>>>>> of
>>>>>>>>>>>> them and save, everything looks fine. However, when I append
>> this
>>>>>>>>> filled
>>>>>>>>>>>> PDF to another one, xpdf doesn't display the values anymore and
>>>>>>>>> complains
>>>>>>>>>>>> about missing fonts:
>>>>>>>>>>>>
>>>>>>>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
>>>>>>>>>>>> Syntax Error: Unknown font in field's DA string
>>>>>>>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
>>>>>>>>>>>> Syntax Error: Unknown font in field's DA string
>>>>>>>>>>>>
>>>>>>>>>>>> I'm using JRuby (9k), but I hope it's understandable for you. I
>>>> put
>>>>>>>>> the
>>>>>>>>>>>> source & PDFs in this gist:
>>>>>>>>>>>> https://gist.github.com/iGEL/a8484f0bc44b03fa9de1 (Will delete
>> it
>>>>>>>>> later,
>>>>>>>>>>>> once the issue is solved)
>>>>>>>>>>>>
>>>>>>>>>>>> Other specs: pdfbox-app-1.8.10, openjdk 1.8.0_66, Debian Jessy
>>>>>> inside
>>>>>>>>> of
>>>>>>>>>>>> Docker
>>>>>>>>>>>>
>>>>>>>>>>>> As you can see, I use a special way to set the values. I had
>>>>>> problems
>>>>>>>>>>> with
>>>>>>>>>>>> German umlauts using setValue and it also sometimes fails
>>>> (Possibly
>>>>>>>>>>> related
>>>>>>>>>>>> to https://issues.apache.org/jira/browse/PDFBOX-1550, the
>> message
>>>>>> is
>>>>>>>>> the
>>>>>>>>>>>> same as in that bug)
>>>>>>>>>>>
>>>>>>>>>>> setting the field value directly using
>>>>>>>>>>>
>>>>>>>>>>> form.getField(name).getDictionary.setItem(
>>>>>>>>>>> Java::OrgApachePdfboxCos::COSName::V,
>>>>>>>>>>> Java::OrgApachePdfboxCos::COSString.new(value)
>>>>>>>>>>> )
>>>>>>>>>>>
>>>>>>>>>>> will not update the visual appearance of the filed and as a
>> result
>>>>>> the
>>>>>>>>>>> newly set value is not visible
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> The COVER_PAGE.pdf and BIW_FORM.pdf are the templates I'm using,
>>>>>>>>>>>> form_filled.pdf is just the BIW_FORM.pdf with 2 fields filled
>> and
>>>>>>>>> merged
>>>>>>>>>>> is
>>>>>>>>>>>> COVER_PAGE.pdf and form_filled.pdf merged together.
>>>>>>>>>>>>
>>>>>>>>>>>> The p in line 15 and 22 print out the DA value of the field and
>>>> it's
>>>>>>>>> the
>>>>>>>>>>>> same for both files:
>>>>>>>>>>>>
>>>>>>>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" #
>> form_filled.pdf
>>>>>>>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # merged.pdf
>>>>>>>>>>>
>>>>>>>>>>> the font resource is called /ProximaNova-Regular but that's not
>> in
>>>>>> your
>>>>>>>>>>> PDF as the font which is in your PDF is called
>>>>>>>>> /MHGLSX+ProximaNova-Regular.
>>>>>>>>>>> In addition the issue with a font subset is that only certain
>>>>>>>>> characters
>>>>>>>>>>> are part of that subset. As a result some of the characters you
>>>> need
>>>>>> to
>>>>>>>>>>> display your field value might not be within the subset.
>>>>>>>>>>>
>>>>>>>>>>> BR
>>>>>>>>>>> Maruan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This font is according to pdffonts in both files:
>>>>>>>>>>>>
>>>>>>>>>>>> $ pdffonts form_filled.pdf
>>>>>>>>>>>> name type encoding
>>>>>>>>>>> emb
>>>>>>>>>>>> sub uni object ID
>>>>>>>>>>>> ------------------------------------ -----------------
>>>>>>>>> ----------------
>>>>>>>>>>> ---
>>>>>>>>>>>> --- --- ---------
>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 124 0
>>>>>>>>>>>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
>>>>>>>>>>>> yes yes yes 125 0*
>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 126 0
>>>>>>>>>>>> MHGLSX+Facit-Bold Type 1C Custom
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 127 0
>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 218 0
>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 219 0
>>>>>>>>>>>> ProximaNova-Bold Type 1C (OT) Custom
>>>>>>>>>>> yes
>>>>>>>>>>>> no no 8 0
>>>>>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
>>>>>>>>>>> yes
>>>>>>>>>>>> no no 9 0
>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 251 0
>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 252 0
>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 254 0
>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 255 0
>>>>>>>>>>>> FJORTL+ProximaNova-Light CID Type 0C
>> Identity-H
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 165 0
>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 259 0
>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 260 0
>>>>>>>>>>>>
>>>>>>>>>>>> $pdffonts merged.pdf
>>>>>>>>>>>> name type encoding
>>>>>>>>>>> emb
>>>>>>>>>>>> sub uni object ID
>>>>>>>>>>>> ------------------------------------ -----------------
>>>>>>>>> ----------------
>>>>>>>>>>> ---
>>>>>>>>>>>> --- --- ---------
>>>>>>>>>>>> AYOVHV+Facit-Bold Type 1C Custom
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 131 0
>>>>>>>>>>>> AYOVHV+ProximaNova-Bold Type 1C Custom
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 132 0
>>>>>>>>>>>> AYOVHV+ProximaNova-Light Type 1C Custom
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 133 0
>>>>>>>>>>>> AYOVHV+ProximaNova-Semibold Type 1C WinAnsi
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 134 0
>>>>>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
>>>>>>>>>>> yes
>>>>>>>>>>>> no no 9 0
>>>>>>>>>>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
>>>>>>>>>>> yes
>>>>>>>>>>>> yes no 192 0
>>>>>>>>>>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
>>>>>>>>>>> yes
>>>>>>>>>>>> yes no 193 0
>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 275 0
>>>>>>>>>>>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
>>>>>>>>>>>> yes yes yes 276 0*
>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 277 0
>>>>>>>>>>>> MHGLSX+Facit-Bold Type 1C Custom
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 278 0
>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 437 0
>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 438 0
>>>>>>>>>>>> ProximaNova-Bold Type 1C (OT) Custom
>>>>>>>>>>> yes
>>>>>>>>>>>> no no 462 0
>>>>>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
>>>>>>>>>>> yes
>>>>>>>>>>>> no no 512 0
>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 500 0
>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 501 0
>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 503 0
>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 504 0
>>>>>>>>>>>> FJORTL+ProximaNova-Light CID Type 0C
>> Identity-H
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 377 0
>>>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 451 0
>>>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>>>>>> yes
>>>>>>>>>>>> yes yes 452 0
>>>>>>>>>>>>
>>>>>>>>>>>> Why are the field values not showing up and how can I fix that?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for your help!
>>>>>>>>>>>>
>>>>>>>>>>>> Johannes
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Weird issue with fonts in input fields after merging
Posted by Johannes Barre <jo...@billfront.com>.
Cool, thank you! :)
On Wed, Oct 14, 2015 at 12:03 PM, Maruan Sahyoun <sa...@fileaffairs.de>
wrote:
> Hi Johannes,
>
>
> > Am 14.10.2015 um 11:51 schrieb Johannes Barre <
> johannes.barre@billfront.com>:
> >
> > Hello Maruan!
> >
> > Thank you for your help. I ported my real app to use the
> > pdfbox-app-2.0.0-20151010.170237-1722.jar snapshot. The fields are filled
> > correctly and show up in all programs I tried.
> >
> > However, somehow the text color in the fields is black. I spend quite
> some
> > time investigating why, but my knowledge of PDF internals is just too
> > limited. The text fields have a DA value of "/ProximaNova-Regular 9 Tf
> > 0.019 0.305 0.627 rg", and I assume, these three numbers are the RGB
> values
> > on a scale from 0 to 1. That would give me the color #054ea1, which is
> > correct. So why is it showing up in black? When focus the field in
> > AcrobatReader, it changes to the correct blue, so probably some other
> value
> > is responsible for the non-focused color. I wasn't able to figure out,
> > which.
> >
>
> the reason is unfortunately very simple - the color setting in the DA
> string is not (yet) respected when creating the appearance stream i.e. the
> visual presentation of the field.
>
> I've created https://issues.apache.org/jira/browse/PDFBOX-3023 for that.
>
> BR
> Maruan
>
>
> > Greets, Johannes
> >
> > On Fri, Oct 9, 2015 at 8:05 PM, Maruan Sahyoun <sa...@fileaffairs.de>
> > wrote:
> >
> >> Hi,
> >>
> >>> Am 09.10.2015 um 18:28 schrieb Johannes Barre <
> >> johannes.barre@billfront.com>:
> >>>
> >>> Hello Maruan!
> >>>
> >>> I don't want to push you, but even if you couldn't figure out
> everything,
> >>> also intermediate results or even just ideas could be helpful.
> >>>
> >>> I experimented a bit more and found, that setValue sometimes works with
> >>> umlauts and sometimes doesn't when I use setValue instead of my hack.
> So,
> >>> with the BIW_FORM.pdf, they are scrambled, but with the umlauts_ok.pdf,
> >>> they are fine. Any idea, why they are scrambled in the BIW_FORM.pdf?
> Do I
> >>> need to convert the character encoding? How do I detect which encoding
> is
> >>> required?
> >>>
> >>
> >> the 1.8 (and previous) version were not really dealing correctly with
> >> character encodings specially if the font is subset. 2.0 does that
> >> correctly. I did a quick hack to support encode() for Type 1 C fonts and
> >> after that your form works fine even with the umlaut.
> >>
> >> I've created https://issues.apache.org/jira/browse/PDFBOX-3016 <
> >> https://issues.apache.org/jira/browse/PDFBOX-3016> for that.
> >>
> >> BR
> >> Maruan
> >>
> >>> If I could fix this issue, I probably could use setValue. When using
> >>> setValue, the values show up in Acrobat Reader even when I merge the
> >>> documents :D
> >>>
> >>> Greets, Johannes
> >>>
> >>> On Thu, Oct 8, 2015 at 4:35 PM, Maruan Sahyoun <sahyoun@fileaffairs.de
> >
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>>> Am 08.10.2015 um 16:31 schrieb Johannes Barre <
> >>>> johannes.barre@billfront.com>:
> >>>>>
> >>>>> Hello!
> >>>>>
> >>>>> I just tried the 2.0 snapshot from yesterday and get this error:
> >>>>>
> >>>>> org/apache/pdfbox/pdmodel/font/PDType1CFont.java:283:in `encode':
> >>>>> java.lang.UnsupportedOperationException: Not implemented: Type1C
> >>>>
> >>>> there is already a ticket for that.
> >>>>
> >>>> BR Maruan
> >>>>
> >>>>>
> >>>>> Is that also true for 1.8.10 (just without the error) and could it be
> >>>>> related to the problem?
> >>>>>
> >>>>> Greets, Johannes
> >>>>>
> >>>>> PS: I've also pushed a Java version of my code to the gist. It's
> >> probably
> >>>>> as messy as my JRuby version, they're just experiments.
> >>>>>
> >>>>> On Thu, Oct 8, 2015 at 3:41 PM, Johannes Barre <
> >>>> johannes.barre@billfront.com
> >>>>>> wrote:
> >>>>>
> >>>>>> Hello Maruan!
> >>>>>>
> >>>>>> Thank again. I hope my last answer didn't sounded too aggressive
> >>>> (written
> >>>>>> communication is difficult). I'm grateful for any help!
> >>>>>>
> >>>>>> You brought up a good point, as a Linux user I've only checked with
> >>>> Google
> >>>>>> Chrome & xpdf (and I was referring to the xpdf). In the Acrobat
> >> Reader 9
> >>>>>> (Linux) and XI (Win XP), the field values are not shown. So I got a
> >> new
> >>>>>> problem :'(
> >>>>>>
> >>>>>> Greets, Johannes
> >>>>>>
> >>>>>> On Thu, Oct 8, 2015 at 3:00 PM, Maruan Sahyoun <
> >> sahyoun@fileaffairs.de>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>>>> Am 08.10.2015 um 14:53 schrieb Johannes Barre <
> >>>>>>>> johannes.barre@billfront.com>:
> >>>>>>>>
> >>>>>>>> Hello Maruan!
> >>>>>>>>
> >>>>>>>> Thank you for your reply.
> >>>>>>>>
> >>>>>>>> So, basically you say, the source PDFs aren't valid already? I've
> >>>> asked
> >>>>>>> and
> >>>>>>>> they were created with Adobe InDesign, I would hope that Adobe
> knows
> >>>>>>> how to
> >>>>>>>> generate valid PDFs. :-/
> >>>>>>>
> >>>>>>> the PDFs are not invalid - that's not what I wanted to say.
> >>>>>>>
> >>>>>>>> But even so, why is everything looking good when I just fill in
> the
> >>>>>>> fields
> >>>>>>>> without merging it? It has the same issue with the fonts name and
> I
> >>>>>>> filled
> >>>>>>>> the field with the same method.
> >>>>>>>
> >>>>>>> when you say looking good - are you looking at it with Adobe Reader
> >> or
> >>>>>>> XPDF or ….
> >>>>>>>
> >>>>>>> I can have a more in-depth look tonight - my comments were about
> the
> >>>>>>> quick observations I made.
> >>>>>>>
> >>>>>>> BR
> >>>>>>> Maruan
> >>>>>>>
> >>>>>>>> Greets, Johannes
> >>>>>>>>
> >>>>>>>> On Thu, Oct 8, 2015 at 2:35 PM, Maruan Sahyoun <
> >>>> sahyoun@fileaffairs.de>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>>>> Am 08.10.2015 um 13:30 schrieb Johannes Barre <
> >>>>>>>>>> johannes.barre@billfront.com>:
> >>>>>>>>>>
> >>>>>>>>>> Hello!
> >>>>>>>>>>
> >>>>>>>>>> I have a weird issue. So, I have to PDFs. When I fill form
> fields
> >> in
> >>>>>>> one
> >>>>>>>>> of
> >>>>>>>>>> them and save, everything looks fine. However, when I append
> this
> >>>>>>> filled
> >>>>>>>>>> PDF to another one, xpdf doesn't display the values anymore and
> >>>>>>> complains
> >>>>>>>>>> about missing fonts:
> >>>>>>>>>>
> >>>>>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
> >>>>>>>>>> Syntax Error: Unknown font in field's DA string
> >>>>>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
> >>>>>>>>>> Syntax Error: Unknown font in field's DA string
> >>>>>>>>>>
> >>>>>>>>>> I'm using JRuby (9k), but I hope it's understandable for you. I
> >> put
> >>>>>>> the
> >>>>>>>>>> source & PDFs in this gist:
> >>>>>>>>>> https://gist.github.com/iGEL/a8484f0bc44b03fa9de1 (Will delete
> it
> >>>>>>> later,
> >>>>>>>>>> once the issue is solved)
> >>>>>>>>>>
> >>>>>>>>>> Other specs: pdfbox-app-1.8.10, openjdk 1.8.0_66, Debian Jessy
> >>>> inside
> >>>>>>> of
> >>>>>>>>>> Docker
> >>>>>>>>>>
> >>>>>>>>>> As you can see, I use a special way to set the values. I had
> >>>> problems
> >>>>>>>>> with
> >>>>>>>>>> German umlauts using setValue and it also sometimes fails
> >> (Possibly
> >>>>>>>>> related
> >>>>>>>>>> to https://issues.apache.org/jira/browse/PDFBOX-1550, the
> message
> >>>> is
> >>>>>>> the
> >>>>>>>>>> same as in that bug)
> >>>>>>>>>
> >>>>>>>>> setting the field value directly using
> >>>>>>>>>
> >>>>>>>>> form.getField(name).getDictionary.setItem(
> >>>>>>>>> Java::OrgApachePdfboxCos::COSName::V,
> >>>>>>>>> Java::OrgApachePdfboxCos::COSString.new(value)
> >>>>>>>>> )
> >>>>>>>>>
> >>>>>>>>> will not update the visual appearance of the filed and as a
> result
> >>>> the
> >>>>>>>>> newly set value is not visible
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> The COVER_PAGE.pdf and BIW_FORM.pdf are the templates I'm using,
> >>>>>>>>>> form_filled.pdf is just the BIW_FORM.pdf with 2 fields filled
> and
> >>>>>>> merged
> >>>>>>>>> is
> >>>>>>>>>> COVER_PAGE.pdf and form_filled.pdf merged together.
> >>>>>>>>>>
> >>>>>>>>>> The p in line 15 and 22 print out the DA value of the field and
> >> it's
> >>>>>>> the
> >>>>>>>>>> same for both files:
> >>>>>>>>>>
> >>>>>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" #
> form_filled.pdf
> >>>>>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # merged.pdf
> >>>>>>>>>
> >>>>>>>>> the font resource is called /ProximaNova-Regular but that's not
> in
> >>>> your
> >>>>>>>>> PDF as the font which is in your PDF is called
> >>>>>>> /MHGLSX+ProximaNova-Regular.
> >>>>>>>>> In addition the issue with a font subset is that only certain
> >>>>>>> characters
> >>>>>>>>> are part of that subset. As a result some of the characters you
> >> need
> >>>> to
> >>>>>>>>> display your field value might not be within the subset.
> >>>>>>>>>
> >>>>>>>>> BR
> >>>>>>>>> Maruan
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> This font is according to pdffonts in both files:
> >>>>>>>>>>
> >>>>>>>>>> $ pdffonts form_filled.pdf
> >>>>>>>>>> name type encoding
> >>>>>>>>> emb
> >>>>>>>>>> sub uni object ID
> >>>>>>>>>> ------------------------------------ -----------------
> >>>>>>> ----------------
> >>>>>>>>> ---
> >>>>>>>>>> --- --- ---------
> >>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 124 0
> >>>>>>>>>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
> >>>>>>>>>> yes yes yes 125 0*
> >>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 126 0
> >>>>>>>>>> MHGLSX+Facit-Bold Type 1C Custom
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 127 0
> >>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 218 0
> >>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 219 0
> >>>>>>>>>> ProximaNova-Bold Type 1C (OT) Custom
> >>>>>>>>> yes
> >>>>>>>>>> no no 8 0
> >>>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
> >>>>>>>>> yes
> >>>>>>>>>> no no 9 0
> >>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 251 0
> >>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 252 0
> >>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 254 0
> >>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 255 0
> >>>>>>>>>> FJORTL+ProximaNova-Light CID Type 0C
> Identity-H
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 165 0
> >>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 259 0
> >>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 260 0
> >>>>>>>>>>
> >>>>>>>>>> $pdffonts merged.pdf
> >>>>>>>>>> name type encoding
> >>>>>>>>> emb
> >>>>>>>>>> sub uni object ID
> >>>>>>>>>> ------------------------------------ -----------------
> >>>>>>> ----------------
> >>>>>>>>> ---
> >>>>>>>>>> --- --- ---------
> >>>>>>>>>> AYOVHV+Facit-Bold Type 1C Custom
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 131 0
> >>>>>>>>>> AYOVHV+ProximaNova-Bold Type 1C Custom
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 132 0
> >>>>>>>>>> AYOVHV+ProximaNova-Light Type 1C Custom
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 133 0
> >>>>>>>>>> AYOVHV+ProximaNova-Semibold Type 1C WinAnsi
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 134 0
> >>>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
> >>>>>>>>> yes
> >>>>>>>>>> no no 9 0
> >>>>>>>>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>>>> yes
> >>>>>>>>>> yes no 192 0
> >>>>>>>>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>>>> yes
> >>>>>>>>>> yes no 193 0
> >>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 275 0
> >>>>>>>>>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
> >>>>>>>>>> yes yes yes 276 0*
> >>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 277 0
> >>>>>>>>>> MHGLSX+Facit-Bold Type 1C Custom
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 278 0
> >>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 437 0
> >>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 438 0
> >>>>>>>>>> ProximaNova-Bold Type 1C (OT) Custom
> >>>>>>>>> yes
> >>>>>>>>>> no no 462 0
> >>>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
> >>>>>>>>> yes
> >>>>>>>>>> no no 512 0
> >>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 500 0
> >>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 501 0
> >>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 503 0
> >>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 504 0
> >>>>>>>>>> FJORTL+ProximaNova-Light CID Type 0C
> Identity-H
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 377 0
> >>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 451 0
> >>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>>>> yes
> >>>>>>>>>> yes yes 452 0
> >>>>>>>>>>
> >>>>>>>>>> Why are the field values not showing up and how can I fix that?
> >>>>>>>>>>
> >>>>>>>>>> Thanks for your help!
> >>>>>>>>>>
> >>>>>>>>>> Johannes
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> >>>>>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> >>>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> >>>> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>>>
> >>>>
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
>
Re: Weird issue with fonts in input fields after merging
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi Johannes,
> Am 14.10.2015 um 11:51 schrieb Johannes Barre <jo...@billfront.com>:
>
> Hello Maruan!
>
> Thank you for your help. I ported my real app to use the
> pdfbox-app-2.0.0-20151010.170237-1722.jar snapshot. The fields are filled
> correctly and show up in all programs I tried.
>
> However, somehow the text color in the fields is black. I spend quite some
> time investigating why, but my knowledge of PDF internals is just too
> limited. The text fields have a DA value of "/ProximaNova-Regular 9 Tf
> 0.019 0.305 0.627 rg", and I assume, these three numbers are the RGB values
> on a scale from 0 to 1. That would give me the color #054ea1, which is
> correct. So why is it showing up in black? When focus the field in
> AcrobatReader, it changes to the correct blue, so probably some other value
> is responsible for the non-focused color. I wasn't able to figure out,
> which.
>
the reason is unfortunately very simple - the color setting in the DA string is not (yet) respected when creating the appearance stream i.e. the visual presentation of the field.
I've created https://issues.apache.org/jira/browse/PDFBOX-3023 for that.
BR
Maruan
> Greets, Johannes
>
> On Fri, Oct 9, 2015 at 8:05 PM, Maruan Sahyoun <sa...@fileaffairs.de>
> wrote:
>
>> Hi,
>>
>>> Am 09.10.2015 um 18:28 schrieb Johannes Barre <
>> johannes.barre@billfront.com>:
>>>
>>> Hello Maruan!
>>>
>>> I don't want to push you, but even if you couldn't figure out everything,
>>> also intermediate results or even just ideas could be helpful.
>>>
>>> I experimented a bit more and found, that setValue sometimes works with
>>> umlauts and sometimes doesn't when I use setValue instead of my hack. So,
>>> with the BIW_FORM.pdf, they are scrambled, but with the umlauts_ok.pdf,
>>> they are fine. Any idea, why they are scrambled in the BIW_FORM.pdf? Do I
>>> need to convert the character encoding? How do I detect which encoding is
>>> required?
>>>
>>
>> the 1.8 (and previous) version were not really dealing correctly with
>> character encodings specially if the font is subset. 2.0 does that
>> correctly. I did a quick hack to support encode() for Type 1 C fonts and
>> after that your form works fine even with the umlaut.
>>
>> I've created https://issues.apache.org/jira/browse/PDFBOX-3016 <
>> https://issues.apache.org/jira/browse/PDFBOX-3016> for that.
>>
>> BR
>> Maruan
>>
>>> If I could fix this issue, I probably could use setValue. When using
>>> setValue, the values show up in Acrobat Reader even when I merge the
>>> documents :D
>>>
>>> Greets, Johannes
>>>
>>> On Thu, Oct 8, 2015 at 4:35 PM, Maruan Sahyoun <sa...@fileaffairs.de>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>>> Am 08.10.2015 um 16:31 schrieb Johannes Barre <
>>>> johannes.barre@billfront.com>:
>>>>>
>>>>> Hello!
>>>>>
>>>>> I just tried the 2.0 snapshot from yesterday and get this error:
>>>>>
>>>>> org/apache/pdfbox/pdmodel/font/PDType1CFont.java:283:in `encode':
>>>>> java.lang.UnsupportedOperationException: Not implemented: Type1C
>>>>
>>>> there is already a ticket for that.
>>>>
>>>> BR Maruan
>>>>
>>>>>
>>>>> Is that also true for 1.8.10 (just without the error) and could it be
>>>>> related to the problem?
>>>>>
>>>>> Greets, Johannes
>>>>>
>>>>> PS: I've also pushed a Java version of my code to the gist. It's
>> probably
>>>>> as messy as my JRuby version, they're just experiments.
>>>>>
>>>>> On Thu, Oct 8, 2015 at 3:41 PM, Johannes Barre <
>>>> johannes.barre@billfront.com
>>>>>> wrote:
>>>>>
>>>>>> Hello Maruan!
>>>>>>
>>>>>> Thank again. I hope my last answer didn't sounded too aggressive
>>>> (written
>>>>>> communication is difficult). I'm grateful for any help!
>>>>>>
>>>>>> You brought up a good point, as a Linux user I've only checked with
>>>> Google
>>>>>> Chrome & xpdf (and I was referring to the xpdf). In the Acrobat
>> Reader 9
>>>>>> (Linux) and XI (Win XP), the field values are not shown. So I got a
>> new
>>>>>> problem :'(
>>>>>>
>>>>>> Greets, Johannes
>>>>>>
>>>>>> On Thu, Oct 8, 2015 at 3:00 PM, Maruan Sahyoun <
>> sahyoun@fileaffairs.de>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>>> Am 08.10.2015 um 14:53 schrieb Johannes Barre <
>>>>>>>> johannes.barre@billfront.com>:
>>>>>>>>
>>>>>>>> Hello Maruan!
>>>>>>>>
>>>>>>>> Thank you for your reply.
>>>>>>>>
>>>>>>>> So, basically you say, the source PDFs aren't valid already? I've
>>>> asked
>>>>>>> and
>>>>>>>> they were created with Adobe InDesign, I would hope that Adobe knows
>>>>>>> how to
>>>>>>>> generate valid PDFs. :-/
>>>>>>>
>>>>>>> the PDFs are not invalid - that's not what I wanted to say.
>>>>>>>
>>>>>>>> But even so, why is everything looking good when I just fill in the
>>>>>>> fields
>>>>>>>> without merging it? It has the same issue with the fonts name and I
>>>>>>> filled
>>>>>>>> the field with the same method.
>>>>>>>
>>>>>>> when you say looking good - are you looking at it with Adobe Reader
>> or
>>>>>>> XPDF or ….
>>>>>>>
>>>>>>> I can have a more in-depth look tonight - my comments were about the
>>>>>>> quick observations I made.
>>>>>>>
>>>>>>> BR
>>>>>>> Maruan
>>>>>>>
>>>>>>>> Greets, Johannes
>>>>>>>>
>>>>>>>> On Thu, Oct 8, 2015 at 2:35 PM, Maruan Sahyoun <
>>>> sahyoun@fileaffairs.de>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>>> Am 08.10.2015 um 13:30 schrieb Johannes Barre <
>>>>>>>>>> johannes.barre@billfront.com>:
>>>>>>>>>>
>>>>>>>>>> Hello!
>>>>>>>>>>
>>>>>>>>>> I have a weird issue. So, I have to PDFs. When I fill form fields
>> in
>>>>>>> one
>>>>>>>>> of
>>>>>>>>>> them and save, everything looks fine. However, when I append this
>>>>>>> filled
>>>>>>>>>> PDF to another one, xpdf doesn't display the values anymore and
>>>>>>> complains
>>>>>>>>>> about missing fonts:
>>>>>>>>>>
>>>>>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
>>>>>>>>>> Syntax Error: Unknown font in field's DA string
>>>>>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
>>>>>>>>>> Syntax Error: Unknown font in field's DA string
>>>>>>>>>>
>>>>>>>>>> I'm using JRuby (9k), but I hope it's understandable for you. I
>> put
>>>>>>> the
>>>>>>>>>> source & PDFs in this gist:
>>>>>>>>>> https://gist.github.com/iGEL/a8484f0bc44b03fa9de1 (Will delete it
>>>>>>> later,
>>>>>>>>>> once the issue is solved)
>>>>>>>>>>
>>>>>>>>>> Other specs: pdfbox-app-1.8.10, openjdk 1.8.0_66, Debian Jessy
>>>> inside
>>>>>>> of
>>>>>>>>>> Docker
>>>>>>>>>>
>>>>>>>>>> As you can see, I use a special way to set the values. I had
>>>> problems
>>>>>>>>> with
>>>>>>>>>> German umlauts using setValue and it also sometimes fails
>> (Possibly
>>>>>>>>> related
>>>>>>>>>> to https://issues.apache.org/jira/browse/PDFBOX-1550, the message
>>>> is
>>>>>>> the
>>>>>>>>>> same as in that bug)
>>>>>>>>>
>>>>>>>>> setting the field value directly using
>>>>>>>>>
>>>>>>>>> form.getField(name).getDictionary.setItem(
>>>>>>>>> Java::OrgApachePdfboxCos::COSName::V,
>>>>>>>>> Java::OrgApachePdfboxCos::COSString.new(value)
>>>>>>>>> )
>>>>>>>>>
>>>>>>>>> will not update the visual appearance of the filed and as a result
>>>> the
>>>>>>>>> newly set value is not visible
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> The COVER_PAGE.pdf and BIW_FORM.pdf are the templates I'm using,
>>>>>>>>>> form_filled.pdf is just the BIW_FORM.pdf with 2 fields filled and
>>>>>>> merged
>>>>>>>>> is
>>>>>>>>>> COVER_PAGE.pdf and form_filled.pdf merged together.
>>>>>>>>>>
>>>>>>>>>> The p in line 15 and 22 print out the DA value of the field and
>> it's
>>>>>>> the
>>>>>>>>>> same for both files:
>>>>>>>>>>
>>>>>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # form_filled.pdf
>>>>>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # merged.pdf
>>>>>>>>>
>>>>>>>>> the font resource is called /ProximaNova-Regular but that's not in
>>>> your
>>>>>>>>> PDF as the font which is in your PDF is called
>>>>>>> /MHGLSX+ProximaNova-Regular.
>>>>>>>>> In addition the issue with a font subset is that only certain
>>>>>>> characters
>>>>>>>>> are part of that subset. As a result some of the characters you
>> need
>>>> to
>>>>>>>>> display your field value might not be within the subset.
>>>>>>>>>
>>>>>>>>> BR
>>>>>>>>> Maruan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This font is according to pdffonts in both files:
>>>>>>>>>>
>>>>>>>>>> $ pdffonts form_filled.pdf
>>>>>>>>>> name type encoding
>>>>>>>>> emb
>>>>>>>>>> sub uni object ID
>>>>>>>>>> ------------------------------------ -----------------
>>>>>>> ----------------
>>>>>>>>> ---
>>>>>>>>>> --- --- ---------
>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
>>>>>>>>> yes
>>>>>>>>>> yes yes 124 0
>>>>>>>>>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
>>>>>>>>>> yes yes yes 125 0*
>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
>>>>>>>>> yes
>>>>>>>>>> yes yes 126 0
>>>>>>>>>> MHGLSX+Facit-Bold Type 1C Custom
>>>>>>>>> yes
>>>>>>>>>> yes yes 127 0
>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>>>> yes
>>>>>>>>>> yes yes 218 0
>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>>>> yes
>>>>>>>>>> yes yes 219 0
>>>>>>>>>> ProximaNova-Bold Type 1C (OT) Custom
>>>>>>>>> yes
>>>>>>>>>> no no 8 0
>>>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
>>>>>>>>> yes
>>>>>>>>>> no no 9 0
>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>>>> yes
>>>>>>>>>> yes yes 251 0
>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>>>> yes
>>>>>>>>>> yes yes 252 0
>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>>>> yes
>>>>>>>>>> yes yes 254 0
>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>>>> yes
>>>>>>>>>> yes yes 255 0
>>>>>>>>>> FJORTL+ProximaNova-Light CID Type 0C Identity-H
>>>>>>>>> yes
>>>>>>>>>> yes yes 165 0
>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>>>> yes
>>>>>>>>>> yes yes 259 0
>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>>>> yes
>>>>>>>>>> yes yes 260 0
>>>>>>>>>>
>>>>>>>>>> $pdffonts merged.pdf
>>>>>>>>>> name type encoding
>>>>>>>>> emb
>>>>>>>>>> sub uni object ID
>>>>>>>>>> ------------------------------------ -----------------
>>>>>>> ----------------
>>>>>>>>> ---
>>>>>>>>>> --- --- ---------
>>>>>>>>>> AYOVHV+Facit-Bold Type 1C Custom
>>>>>>>>> yes
>>>>>>>>>> yes yes 131 0
>>>>>>>>>> AYOVHV+ProximaNova-Bold Type 1C Custom
>>>>>>>>> yes
>>>>>>>>>> yes yes 132 0
>>>>>>>>>> AYOVHV+ProximaNova-Light Type 1C Custom
>>>>>>>>> yes
>>>>>>>>>> yes yes 133 0
>>>>>>>>>> AYOVHV+ProximaNova-Semibold Type 1C WinAnsi
>>>>>>>>> yes
>>>>>>>>>> yes yes 134 0
>>>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
>>>>>>>>> yes
>>>>>>>>>> no no 9 0
>>>>>>>>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
>>>>>>>>> yes
>>>>>>>>>> yes no 192 0
>>>>>>>>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
>>>>>>>>> yes
>>>>>>>>>> yes no 193 0
>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
>>>>>>>>> yes
>>>>>>>>>> yes yes 275 0
>>>>>>>>>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
>>>>>>>>>> yes yes yes 276 0*
>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
>>>>>>>>> yes
>>>>>>>>>> yes yes 277 0
>>>>>>>>>> MHGLSX+Facit-Bold Type 1C Custom
>>>>>>>>> yes
>>>>>>>>>> yes yes 278 0
>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>>>> yes
>>>>>>>>>> yes yes 437 0
>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>>>> yes
>>>>>>>>>> yes yes 438 0
>>>>>>>>>> ProximaNova-Bold Type 1C (OT) Custom
>>>>>>>>> yes
>>>>>>>>>> no no 462 0
>>>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
>>>>>>>>> yes
>>>>>>>>>> no no 512 0
>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>>>> yes
>>>>>>>>>> yes yes 500 0
>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>>>> yes
>>>>>>>>>> yes yes 501 0
>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>>>> yes
>>>>>>>>>> yes yes 503 0
>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>>>> yes
>>>>>>>>>> yes yes 504 0
>>>>>>>>>> FJORTL+ProximaNova-Light CID Type 0C Identity-H
>>>>>>>>> yes
>>>>>>>>>> yes yes 377 0
>>>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>>>> yes
>>>>>>>>>> yes yes 451 0
>>>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>>>> yes
>>>>>>>>>> yes yes 452 0
>>>>>>>>>>
>>>>>>>>>> Why are the field values not showing up and how can I fix that?
>>>>>>>>>>
>>>>>>>>>> Thanks for your help!
>>>>>>>>>>
>>>>>>>>>> Johannes
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>>
>>>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Weird issue with fonts in input fields after merging
Posted by Johannes Barre <jo...@billfront.com>.
Hello Maruan!
Thank you for your help. I ported my real app to use the
pdfbox-app-2.0.0-20151010.170237-1722.jar snapshot. The fields are filled
correctly and show up in all programs I tried.
However, somehow the text color in the fields is black. I spend quite some
time investigating why, but my knowledge of PDF internals is just too
limited. The text fields have a DA value of "/ProximaNova-Regular 9 Tf
0.019 0.305 0.627 rg", and I assume, these three numbers are the RGB values
on a scale from 0 to 1. That would give me the color #054ea1, which is
correct. So why is it showing up in black? When focus the field in
AcrobatReader, it changes to the correct blue, so probably some other value
is responsible for the non-focused color. I wasn't able to figure out,
which.
Greets, Johannes
On Fri, Oct 9, 2015 at 8:05 PM, Maruan Sahyoun <sa...@fileaffairs.de>
wrote:
> Hi,
>
> > Am 09.10.2015 um 18:28 schrieb Johannes Barre <
> johannes.barre@billfront.com>:
> >
> > Hello Maruan!
> >
> > I don't want to push you, but even if you couldn't figure out everything,
> > also intermediate results or even just ideas could be helpful.
> >
> > I experimented a bit more and found, that setValue sometimes works with
> > umlauts and sometimes doesn't when I use setValue instead of my hack. So,
> > with the BIW_FORM.pdf, they are scrambled, but with the umlauts_ok.pdf,
> > they are fine. Any idea, why they are scrambled in the BIW_FORM.pdf? Do I
> > need to convert the character encoding? How do I detect which encoding is
> > required?
> >
>
> the 1.8 (and previous) version were not really dealing correctly with
> character encodings specially if the font is subset. 2.0 does that
> correctly. I did a quick hack to support encode() for Type 1 C fonts and
> after that your form works fine even with the umlaut.
>
> I've created https://issues.apache.org/jira/browse/PDFBOX-3016 <
> https://issues.apache.org/jira/browse/PDFBOX-3016> for that.
>
> BR
> Maruan
>
> > If I could fix this issue, I probably could use setValue. When using
> > setValue, the values show up in Acrobat Reader even when I merge the
> > documents :D
> >
> > Greets, Johannes
> >
> > On Thu, Oct 8, 2015 at 4:35 PM, Maruan Sahyoun <sa...@fileaffairs.de>
> > wrote:
> >
> >> Hi,
> >>
> >>> Am 08.10.2015 um 16:31 schrieb Johannes Barre <
> >> johannes.barre@billfront.com>:
> >>>
> >>> Hello!
> >>>
> >>> I just tried the 2.0 snapshot from yesterday and get this error:
> >>>
> >>> org/apache/pdfbox/pdmodel/font/PDType1CFont.java:283:in `encode':
> >>> java.lang.UnsupportedOperationException: Not implemented: Type1C
> >>
> >> there is already a ticket for that.
> >>
> >> BR Maruan
> >>
> >>>
> >>> Is that also true for 1.8.10 (just without the error) and could it be
> >>> related to the problem?
> >>>
> >>> Greets, Johannes
> >>>
> >>> PS: I've also pushed a Java version of my code to the gist. It's
> probably
> >>> as messy as my JRuby version, they're just experiments.
> >>>
> >>> On Thu, Oct 8, 2015 at 3:41 PM, Johannes Barre <
> >> johannes.barre@billfront.com
> >>>> wrote:
> >>>
> >>>> Hello Maruan!
> >>>>
> >>>> Thank again. I hope my last answer didn't sounded too aggressive
> >> (written
> >>>> communication is difficult). I'm grateful for any help!
> >>>>
> >>>> You brought up a good point, as a Linux user I've only checked with
> >> Google
> >>>> Chrome & xpdf (and I was referring to the xpdf). In the Acrobat
> Reader 9
> >>>> (Linux) and XI (Win XP), the field values are not shown. So I got a
> new
> >>>> problem :'(
> >>>>
> >>>> Greets, Johannes
> >>>>
> >>>> On Thu, Oct 8, 2015 at 3:00 PM, Maruan Sahyoun <
> sahyoun@fileaffairs.de>
> >>>> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>>>> Am 08.10.2015 um 14:53 schrieb Johannes Barre <
> >>>>>> johannes.barre@billfront.com>:
> >>>>>>
> >>>>>> Hello Maruan!
> >>>>>>
> >>>>>> Thank you for your reply.
> >>>>>>
> >>>>>> So, basically you say, the source PDFs aren't valid already? I've
> >> asked
> >>>>> and
> >>>>>> they were created with Adobe InDesign, I would hope that Adobe knows
> >>>>> how to
> >>>>>> generate valid PDFs. :-/
> >>>>>
> >>>>> the PDFs are not invalid - that's not what I wanted to say.
> >>>>>
> >>>>>> But even so, why is everything looking good when I just fill in the
> >>>>> fields
> >>>>>> without merging it? It has the same issue with the fonts name and I
> >>>>> filled
> >>>>>> the field with the same method.
> >>>>>
> >>>>> when you say looking good - are you looking at it with Adobe Reader
> or
> >>>>> XPDF or ….
> >>>>>
> >>>>> I can have a more in-depth look tonight - my comments were about the
> >>>>> quick observations I made.
> >>>>>
> >>>>> BR
> >>>>> Maruan
> >>>>>
> >>>>>> Greets, Johannes
> >>>>>>
> >>>>>> On Thu, Oct 8, 2015 at 2:35 PM, Maruan Sahyoun <
> >> sahyoun@fileaffairs.de>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>>>> Am 08.10.2015 um 13:30 schrieb Johannes Barre <
> >>>>>>>> johannes.barre@billfront.com>:
> >>>>>>>>
> >>>>>>>> Hello!
> >>>>>>>>
> >>>>>>>> I have a weird issue. So, I have to PDFs. When I fill form fields
> in
> >>>>> one
> >>>>>>> of
> >>>>>>>> them and save, everything looks fine. However, when I append this
> >>>>> filled
> >>>>>>>> PDF to another one, xpdf doesn't display the values anymore and
> >>>>> complains
> >>>>>>>> about missing fonts:
> >>>>>>>>
> >>>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
> >>>>>>>> Syntax Error: Unknown font in field's DA string
> >>>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
> >>>>>>>> Syntax Error: Unknown font in field's DA string
> >>>>>>>>
> >>>>>>>> I'm using JRuby (9k), but I hope it's understandable for you. I
> put
> >>>>> the
> >>>>>>>> source & PDFs in this gist:
> >>>>>>>> https://gist.github.com/iGEL/a8484f0bc44b03fa9de1 (Will delete it
> >>>>> later,
> >>>>>>>> once the issue is solved)
> >>>>>>>>
> >>>>>>>> Other specs: pdfbox-app-1.8.10, openjdk 1.8.0_66, Debian Jessy
> >> inside
> >>>>> of
> >>>>>>>> Docker
> >>>>>>>>
> >>>>>>>> As you can see, I use a special way to set the values. I had
> >> problems
> >>>>>>> with
> >>>>>>>> German umlauts using setValue and it also sometimes fails
> (Possibly
> >>>>>>> related
> >>>>>>>> to https://issues.apache.org/jira/browse/PDFBOX-1550, the message
> >> is
> >>>>> the
> >>>>>>>> same as in that bug)
> >>>>>>>
> >>>>>>> setting the field value directly using
> >>>>>>>
> >>>>>>> form.getField(name).getDictionary.setItem(
> >>>>>>> Java::OrgApachePdfboxCos::COSName::V,
> >>>>>>> Java::OrgApachePdfboxCos::COSString.new(value)
> >>>>>>> )
> >>>>>>>
> >>>>>>> will not update the visual appearance of the filed and as a result
> >> the
> >>>>>>> newly set value is not visible
> >>>>>>>
> >>>>>>>
> >>>>>>>> The COVER_PAGE.pdf and BIW_FORM.pdf are the templates I'm using,
> >>>>>>>> form_filled.pdf is just the BIW_FORM.pdf with 2 fields filled and
> >>>>> merged
> >>>>>>> is
> >>>>>>>> COVER_PAGE.pdf and form_filled.pdf merged together.
> >>>>>>>>
> >>>>>>>> The p in line 15 and 22 print out the DA value of the field and
> it's
> >>>>> the
> >>>>>>>> same for both files:
> >>>>>>>>
> >>>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # form_filled.pdf
> >>>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # merged.pdf
> >>>>>>>
> >>>>>>> the font resource is called /ProximaNova-Regular but that's not in
> >> your
> >>>>>>> PDF as the font which is in your PDF is called
> >>>>> /MHGLSX+ProximaNova-Regular.
> >>>>>>> In addition the issue with a font subset is that only certain
> >>>>> characters
> >>>>>>> are part of that subset. As a result some of the characters you
> need
> >> to
> >>>>>>> display your field value might not be within the subset.
> >>>>>>>
> >>>>>>> BR
> >>>>>>> Maruan
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> This font is according to pdffonts in both files:
> >>>>>>>>
> >>>>>>>> $ pdffonts form_filled.pdf
> >>>>>>>> name type encoding
> >>>>>>> emb
> >>>>>>>> sub uni object ID
> >>>>>>>> ------------------------------------ -----------------
> >>>>> ----------------
> >>>>>>> ---
> >>>>>>>> --- --- ---------
> >>>>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
> >>>>>>> yes
> >>>>>>>> yes yes 124 0
> >>>>>>>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
> >>>>>>>> yes yes yes 125 0*
> >>>>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
> >>>>>>> yes
> >>>>>>>> yes yes 126 0
> >>>>>>>> MHGLSX+Facit-Bold Type 1C Custom
> >>>>>>> yes
> >>>>>>>> yes yes 127 0
> >>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>> yes
> >>>>>>>> yes yes 218 0
> >>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>> yes
> >>>>>>>> yes yes 219 0
> >>>>>>>> ProximaNova-Bold Type 1C (OT) Custom
> >>>>>>> yes
> >>>>>>>> no no 8 0
> >>>>>>>> ProximaNova-Light Type 1C (OT) Custom
> >>>>>>> yes
> >>>>>>>> no no 9 0
> >>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>> yes
> >>>>>>>> yes yes 251 0
> >>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>> yes
> >>>>>>>> yes yes 252 0
> >>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>> yes
> >>>>>>>> yes yes 254 0
> >>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>> yes
> >>>>>>>> yes yes 255 0
> >>>>>>>> FJORTL+ProximaNova-Light CID Type 0C Identity-H
> >>>>>>> yes
> >>>>>>>> yes yes 165 0
> >>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>> yes
> >>>>>>>> yes yes 259 0
> >>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>> yes
> >>>>>>>> yes yes 260 0
> >>>>>>>>
> >>>>>>>> $pdffonts merged.pdf
> >>>>>>>> name type encoding
> >>>>>>> emb
> >>>>>>>> sub uni object ID
> >>>>>>>> ------------------------------------ -----------------
> >>>>> ----------------
> >>>>>>> ---
> >>>>>>>> --- --- ---------
> >>>>>>>> AYOVHV+Facit-Bold Type 1C Custom
> >>>>>>> yes
> >>>>>>>> yes yes 131 0
> >>>>>>>> AYOVHV+ProximaNova-Bold Type 1C Custom
> >>>>>>> yes
> >>>>>>>> yes yes 132 0
> >>>>>>>> AYOVHV+ProximaNova-Light Type 1C Custom
> >>>>>>> yes
> >>>>>>>> yes yes 133 0
> >>>>>>>> AYOVHV+ProximaNova-Semibold Type 1C WinAnsi
> >>>>>>> yes
> >>>>>>>> yes yes 134 0
> >>>>>>>> ProximaNova-Light Type 1C (OT) Custom
> >>>>>>> yes
> >>>>>>>> no no 9 0
> >>>>>>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>> yes
> >>>>>>>> yes no 192 0
> >>>>>>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>> yes
> >>>>>>>> yes no 193 0
> >>>>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
> >>>>>>> yes
> >>>>>>>> yes yes 275 0
> >>>>>>>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
> >>>>>>>> yes yes yes 276 0*
> >>>>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
> >>>>>>> yes
> >>>>>>>> yes yes 277 0
> >>>>>>>> MHGLSX+Facit-Bold Type 1C Custom
> >>>>>>> yes
> >>>>>>>> yes yes 278 0
> >>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>> yes
> >>>>>>>> yes yes 437 0
> >>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>> yes
> >>>>>>>> yes yes 438 0
> >>>>>>>> ProximaNova-Bold Type 1C (OT) Custom
> >>>>>>> yes
> >>>>>>>> no no 462 0
> >>>>>>>> ProximaNova-Light Type 1C (OT) Custom
> >>>>>>> yes
> >>>>>>>> no no 512 0
> >>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>> yes
> >>>>>>>> yes yes 500 0
> >>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>> yes
> >>>>>>>> yes yes 501 0
> >>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>> yes
> >>>>>>>> yes yes 503 0
> >>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>> yes
> >>>>>>>> yes yes 504 0
> >>>>>>>> FJORTL+ProximaNova-Light CID Type 0C Identity-H
> >>>>>>> yes
> >>>>>>>> yes yes 377 0
> >>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>>>> yes
> >>>>>>>> yes yes 451 0
> >>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>>>> yes
> >>>>>>>> yes yes 452 0
> >>>>>>>>
> >>>>>>>> Why are the field values not showing up and how can I fix that?
> >>>>>>>>
> >>>>>>>> Thanks for your help!
> >>>>>>>>
> >>>>>>>> Johannes
> >>>>>>>
> >>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> >>>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> >>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> >> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>
> >>
>
>
Re: Weird issue with fonts in input fields after merging
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi,
> Am 09.10.2015 um 18:28 schrieb Johannes Barre <jo...@billfront.com>:
>
> Hello Maruan!
>
> I don't want to push you, but even if you couldn't figure out everything,
> also intermediate results or even just ideas could be helpful.
>
> I experimented a bit more and found, that setValue sometimes works with
> umlauts and sometimes doesn't when I use setValue instead of my hack. So,
> with the BIW_FORM.pdf, they are scrambled, but with the umlauts_ok.pdf,
> they are fine. Any idea, why they are scrambled in the BIW_FORM.pdf? Do I
> need to convert the character encoding? How do I detect which encoding is
> required?
>
the 1.8 (and previous) version were not really dealing correctly with character encodings specially if the font is subset. 2.0 does that correctly. I did a quick hack to support encode() for Type 1 C fonts and after that your form works fine even with the umlaut.
I've created https://issues.apache.org/jira/browse/PDFBOX-3016 <https://issues.apache.org/jira/browse/PDFBOX-3016> for that.
BR
Maruan
> If I could fix this issue, I probably could use setValue. When using
> setValue, the values show up in Acrobat Reader even when I merge the
> documents :D
>
> Greets, Johannes
>
> On Thu, Oct 8, 2015 at 4:35 PM, Maruan Sahyoun <sa...@fileaffairs.de>
> wrote:
>
>> Hi,
>>
>>> Am 08.10.2015 um 16:31 schrieb Johannes Barre <
>> johannes.barre@billfront.com>:
>>>
>>> Hello!
>>>
>>> I just tried the 2.0 snapshot from yesterday and get this error:
>>>
>>> org/apache/pdfbox/pdmodel/font/PDType1CFont.java:283:in `encode':
>>> java.lang.UnsupportedOperationException: Not implemented: Type1C
>>
>> there is already a ticket for that.
>>
>> BR Maruan
>>
>>>
>>> Is that also true for 1.8.10 (just without the error) and could it be
>>> related to the problem?
>>>
>>> Greets, Johannes
>>>
>>> PS: I've also pushed a Java version of my code to the gist. It's probably
>>> as messy as my JRuby version, they're just experiments.
>>>
>>> On Thu, Oct 8, 2015 at 3:41 PM, Johannes Barre <
>> johannes.barre@billfront.com
>>>> wrote:
>>>
>>>> Hello Maruan!
>>>>
>>>> Thank again. I hope my last answer didn't sounded too aggressive
>> (written
>>>> communication is difficult). I'm grateful for any help!
>>>>
>>>> You brought up a good point, as a Linux user I've only checked with
>> Google
>>>> Chrome & xpdf (and I was referring to the xpdf). In the Acrobat Reader 9
>>>> (Linux) and XI (Win XP), the field values are not shown. So I got a new
>>>> problem :'(
>>>>
>>>> Greets, Johannes
>>>>
>>>> On Thu, Oct 8, 2015 at 3:00 PM, Maruan Sahyoun <sa...@fileaffairs.de>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>>> Am 08.10.2015 um 14:53 schrieb Johannes Barre <
>>>>>> johannes.barre@billfront.com>:
>>>>>>
>>>>>> Hello Maruan!
>>>>>>
>>>>>> Thank you for your reply.
>>>>>>
>>>>>> So, basically you say, the source PDFs aren't valid already? I've
>> asked
>>>>> and
>>>>>> they were created with Adobe InDesign, I would hope that Adobe knows
>>>>> how to
>>>>>> generate valid PDFs. :-/
>>>>>
>>>>> the PDFs are not invalid - that's not what I wanted to say.
>>>>>
>>>>>> But even so, why is everything looking good when I just fill in the
>>>>> fields
>>>>>> without merging it? It has the same issue with the fonts name and I
>>>>> filled
>>>>>> the field with the same method.
>>>>>
>>>>> when you say looking good - are you looking at it with Adobe Reader or
>>>>> XPDF or ….
>>>>>
>>>>> I can have a more in-depth look tonight - my comments were about the
>>>>> quick observations I made.
>>>>>
>>>>> BR
>>>>> Maruan
>>>>>
>>>>>> Greets, Johannes
>>>>>>
>>>>>> On Thu, Oct 8, 2015 at 2:35 PM, Maruan Sahyoun <
>> sahyoun@fileaffairs.de>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>>> Am 08.10.2015 um 13:30 schrieb Johannes Barre <
>>>>>>>> johannes.barre@billfront.com>:
>>>>>>>>
>>>>>>>> Hello!
>>>>>>>>
>>>>>>>> I have a weird issue. So, I have to PDFs. When I fill form fields in
>>>>> one
>>>>>>> of
>>>>>>>> them and save, everything looks fine. However, when I append this
>>>>> filled
>>>>>>>> PDF to another one, xpdf doesn't display the values anymore and
>>>>> complains
>>>>>>>> about missing fonts:
>>>>>>>>
>>>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
>>>>>>>> Syntax Error: Unknown font in field's DA string
>>>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
>>>>>>>> Syntax Error: Unknown font in field's DA string
>>>>>>>>
>>>>>>>> I'm using JRuby (9k), but I hope it's understandable for you. I put
>>>>> the
>>>>>>>> source & PDFs in this gist:
>>>>>>>> https://gist.github.com/iGEL/a8484f0bc44b03fa9de1 (Will delete it
>>>>> later,
>>>>>>>> once the issue is solved)
>>>>>>>>
>>>>>>>> Other specs: pdfbox-app-1.8.10, openjdk 1.8.0_66, Debian Jessy
>> inside
>>>>> of
>>>>>>>> Docker
>>>>>>>>
>>>>>>>> As you can see, I use a special way to set the values. I had
>> problems
>>>>>>> with
>>>>>>>> German umlauts using setValue and it also sometimes fails (Possibly
>>>>>>> related
>>>>>>>> to https://issues.apache.org/jira/browse/PDFBOX-1550, the message
>> is
>>>>> the
>>>>>>>> same as in that bug)
>>>>>>>
>>>>>>> setting the field value directly using
>>>>>>>
>>>>>>> form.getField(name).getDictionary.setItem(
>>>>>>> Java::OrgApachePdfboxCos::COSName::V,
>>>>>>> Java::OrgApachePdfboxCos::COSString.new(value)
>>>>>>> )
>>>>>>>
>>>>>>> will not update the visual appearance of the filed and as a result
>> the
>>>>>>> newly set value is not visible
>>>>>>>
>>>>>>>
>>>>>>>> The COVER_PAGE.pdf and BIW_FORM.pdf are the templates I'm using,
>>>>>>>> form_filled.pdf is just the BIW_FORM.pdf with 2 fields filled and
>>>>> merged
>>>>>>> is
>>>>>>>> COVER_PAGE.pdf and form_filled.pdf merged together.
>>>>>>>>
>>>>>>>> The p in line 15 and 22 print out the DA value of the field and it's
>>>>> the
>>>>>>>> same for both files:
>>>>>>>>
>>>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # form_filled.pdf
>>>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # merged.pdf
>>>>>>>
>>>>>>> the font resource is called /ProximaNova-Regular but that's not in
>> your
>>>>>>> PDF as the font which is in your PDF is called
>>>>> /MHGLSX+ProximaNova-Regular.
>>>>>>> In addition the issue with a font subset is that only certain
>>>>> characters
>>>>>>> are part of that subset. As a result some of the characters you need
>> to
>>>>>>> display your field value might not be within the subset.
>>>>>>>
>>>>>>> BR
>>>>>>> Maruan
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> This font is according to pdffonts in both files:
>>>>>>>>
>>>>>>>> $ pdffonts form_filled.pdf
>>>>>>>> name type encoding
>>>>>>> emb
>>>>>>>> sub uni object ID
>>>>>>>> ------------------------------------ -----------------
>>>>> ----------------
>>>>>>> ---
>>>>>>>> --- --- ---------
>>>>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
>>>>>>> yes
>>>>>>>> yes yes 124 0
>>>>>>>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
>>>>>>>> yes yes yes 125 0*
>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
>>>>>>> yes
>>>>>>>> yes yes 126 0
>>>>>>>> MHGLSX+Facit-Bold Type 1C Custom
>>>>>>> yes
>>>>>>>> yes yes 127 0
>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 218 0
>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 219 0
>>>>>>>> ProximaNova-Bold Type 1C (OT) Custom
>>>>>>> yes
>>>>>>>> no no 8 0
>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
>>>>>>> yes
>>>>>>>> no no 9 0
>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 251 0
>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 252 0
>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 254 0
>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 255 0
>>>>>>>> FJORTL+ProximaNova-Light CID Type 0C Identity-H
>>>>>>> yes
>>>>>>>> yes yes 165 0
>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 259 0
>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 260 0
>>>>>>>>
>>>>>>>> $pdffonts merged.pdf
>>>>>>>> name type encoding
>>>>>>> emb
>>>>>>>> sub uni object ID
>>>>>>>> ------------------------------------ -----------------
>>>>> ----------------
>>>>>>> ---
>>>>>>>> --- --- ---------
>>>>>>>> AYOVHV+Facit-Bold Type 1C Custom
>>>>>>> yes
>>>>>>>> yes yes 131 0
>>>>>>>> AYOVHV+ProximaNova-Bold Type 1C Custom
>>>>>>> yes
>>>>>>>> yes yes 132 0
>>>>>>>> AYOVHV+ProximaNova-Light Type 1C Custom
>>>>>>> yes
>>>>>>>> yes yes 133 0
>>>>>>>> AYOVHV+ProximaNova-Semibold Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 134 0
>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
>>>>>>> yes
>>>>>>>> no no 9 0
>>>>>>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes no 192 0
>>>>>>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes no 193 0
>>>>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
>>>>>>> yes
>>>>>>>> yes yes 275 0
>>>>>>>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
>>>>>>>> yes yes yes 276 0*
>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
>>>>>>> yes
>>>>>>>> yes yes 277 0
>>>>>>>> MHGLSX+Facit-Bold Type 1C Custom
>>>>>>> yes
>>>>>>>> yes yes 278 0
>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 437 0
>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 438 0
>>>>>>>> ProximaNova-Bold Type 1C (OT) Custom
>>>>>>> yes
>>>>>>>> no no 462 0
>>>>>>>> ProximaNova-Light Type 1C (OT) Custom
>>>>>>> yes
>>>>>>>> no no 512 0
>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 500 0
>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 501 0
>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 503 0
>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 504 0
>>>>>>>> FJORTL+ProximaNova-Light CID Type 0C Identity-H
>>>>>>> yes
>>>>>>>> yes yes 377 0
>>>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 451 0
>>>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>>>> yes
>>>>>>>> yes yes 452 0
>>>>>>>>
>>>>>>>> Why are the field values not showing up and how can I fix that?
>>>>>>>>
>>>>>>>> Thanks for your help!
>>>>>>>>
>>>>>>>> Johannes
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>>
Re: Weird issue with fonts in input fields after merging
Posted by Johannes Barre <jo...@billfront.com>.
Hello Maruan!
I don't want to push you, but even if you couldn't figure out everything,
also intermediate results or even just ideas could be helpful.
I experimented a bit more and found, that setValue sometimes works with
umlauts and sometimes doesn't when I use setValue instead of my hack. So,
with the BIW_FORM.pdf, they are scrambled, but with the umlauts_ok.pdf,
they are fine. Any idea, why they are scrambled in the BIW_FORM.pdf? Do I
need to convert the character encoding? How do I detect which encoding is
required?
If I could fix this issue, I probably could use setValue. When using
setValue, the values show up in Acrobat Reader even when I merge the
documents :D
Greets, Johannes
On Thu, Oct 8, 2015 at 4:35 PM, Maruan Sahyoun <sa...@fileaffairs.de>
wrote:
> Hi,
>
> > Am 08.10.2015 um 16:31 schrieb Johannes Barre <
> johannes.barre@billfront.com>:
> >
> > Hello!
> >
> > I just tried the 2.0 snapshot from yesterday and get this error:
> >
> > org/apache/pdfbox/pdmodel/font/PDType1CFont.java:283:in `encode':
> > java.lang.UnsupportedOperationException: Not implemented: Type1C
>
> there is already a ticket for that.
>
> BR Maruan
>
> >
> > Is that also true for 1.8.10 (just without the error) and could it be
> > related to the problem?
> >
> > Greets, Johannes
> >
> > PS: I've also pushed a Java version of my code to the gist. It's probably
> > as messy as my JRuby version, they're just experiments.
> >
> > On Thu, Oct 8, 2015 at 3:41 PM, Johannes Barre <
> johannes.barre@billfront.com
> >> wrote:
> >
> >> Hello Maruan!
> >>
> >> Thank again. I hope my last answer didn't sounded too aggressive
> (written
> >> communication is difficult). I'm grateful for any help!
> >>
> >> You brought up a good point, as a Linux user I've only checked with
> Google
> >> Chrome & xpdf (and I was referring to the xpdf). In the Acrobat Reader 9
> >> (Linux) and XI (Win XP), the field values are not shown. So I got a new
> >> problem :'(
> >>
> >> Greets, Johannes
> >>
> >> On Thu, Oct 8, 2015 at 3:00 PM, Maruan Sahyoun <sa...@fileaffairs.de>
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>>>> Am 08.10.2015 um 14:53 schrieb Johannes Barre <
> >>>> johannes.barre@billfront.com>:
> >>>>
> >>>> Hello Maruan!
> >>>>
> >>>> Thank you for your reply.
> >>>>
> >>>> So, basically you say, the source PDFs aren't valid already? I've
> asked
> >>> and
> >>>> they were created with Adobe InDesign, I would hope that Adobe knows
> >>> how to
> >>>> generate valid PDFs. :-/
> >>>
> >>> the PDFs are not invalid - that's not what I wanted to say.
> >>>
> >>>> But even so, why is everything looking good when I just fill in the
> >>> fields
> >>>> without merging it? It has the same issue with the fonts name and I
> >>> filled
> >>>> the field with the same method.
> >>>
> >>> when you say looking good - are you looking at it with Adobe Reader or
> >>> XPDF or ….
> >>>
> >>> I can have a more in-depth look tonight - my comments were about the
> >>> quick observations I made.
> >>>
> >>> BR
> >>> Maruan
> >>>
> >>>> Greets, Johannes
> >>>>
> >>>> On Thu, Oct 8, 2015 at 2:35 PM, Maruan Sahyoun <
> sahyoun@fileaffairs.de>
> >>>> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>>>> Am 08.10.2015 um 13:30 schrieb Johannes Barre <
> >>>>>> johannes.barre@billfront.com>:
> >>>>>>
> >>>>>> Hello!
> >>>>>>
> >>>>>> I have a weird issue. So, I have to PDFs. When I fill form fields in
> >>> one
> >>>>> of
> >>>>>> them and save, everything looks fine. However, when I append this
> >>> filled
> >>>>>> PDF to another one, xpdf doesn't display the values anymore and
> >>> complains
> >>>>>> about missing fonts:
> >>>>>>
> >>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
> >>>>>> Syntax Error: Unknown font in field's DA string
> >>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
> >>>>>> Syntax Error: Unknown font in field's DA string
> >>>>>>
> >>>>>> I'm using JRuby (9k), but I hope it's understandable for you. I put
> >>> the
> >>>>>> source & PDFs in this gist:
> >>>>>> https://gist.github.com/iGEL/a8484f0bc44b03fa9de1 (Will delete it
> >>> later,
> >>>>>> once the issue is solved)
> >>>>>>
> >>>>>> Other specs: pdfbox-app-1.8.10, openjdk 1.8.0_66, Debian Jessy
> inside
> >>> of
> >>>>>> Docker
> >>>>>>
> >>>>>> As you can see, I use a special way to set the values. I had
> problems
> >>>>> with
> >>>>>> German umlauts using setValue and it also sometimes fails (Possibly
> >>>>> related
> >>>>>> to https://issues.apache.org/jira/browse/PDFBOX-1550, the message
> is
> >>> the
> >>>>>> same as in that bug)
> >>>>>
> >>>>> setting the field value directly using
> >>>>>
> >>>>> form.getField(name).getDictionary.setItem(
> >>>>> Java::OrgApachePdfboxCos::COSName::V,
> >>>>> Java::OrgApachePdfboxCos::COSString.new(value)
> >>>>> )
> >>>>>
> >>>>> will not update the visual appearance of the filed and as a result
> the
> >>>>> newly set value is not visible
> >>>>>
> >>>>>
> >>>>>> The COVER_PAGE.pdf and BIW_FORM.pdf are the templates I'm using,
> >>>>>> form_filled.pdf is just the BIW_FORM.pdf with 2 fields filled and
> >>> merged
> >>>>> is
> >>>>>> COVER_PAGE.pdf and form_filled.pdf merged together.
> >>>>>>
> >>>>>> The p in line 15 and 22 print out the DA value of the field and it's
> >>> the
> >>>>>> same for both files:
> >>>>>>
> >>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # form_filled.pdf
> >>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # merged.pdf
> >>>>>
> >>>>> the font resource is called /ProximaNova-Regular but that's not in
> your
> >>>>> PDF as the font which is in your PDF is called
> >>> /MHGLSX+ProximaNova-Regular.
> >>>>> In addition the issue with a font subset is that only certain
> >>> characters
> >>>>> are part of that subset. As a result some of the characters you need
> to
> >>>>> display your field value might not be within the subset.
> >>>>>
> >>>>> BR
> >>>>> Maruan
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> This font is according to pdffonts in both files:
> >>>>>>
> >>>>>> $ pdffonts form_filled.pdf
> >>>>>> name type encoding
> >>>>> emb
> >>>>>> sub uni object ID
> >>>>>> ------------------------------------ -----------------
> >>> ----------------
> >>>>> ---
> >>>>>> --- --- ---------
> >>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
> >>>>> yes
> >>>>>> yes yes 124 0
> >>>>>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
> >>>>>> yes yes yes 125 0*
> >>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
> >>>>> yes
> >>>>>> yes yes 126 0
> >>>>>> MHGLSX+Facit-Bold Type 1C Custom
> >>>>> yes
> >>>>>> yes yes 127 0
> >>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>> yes
> >>>>>> yes yes 218 0
> >>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>> yes
> >>>>>> yes yes 219 0
> >>>>>> ProximaNova-Bold Type 1C (OT) Custom
> >>>>> yes
> >>>>>> no no 8 0
> >>>>>> ProximaNova-Light Type 1C (OT) Custom
> >>>>> yes
> >>>>>> no no 9 0
> >>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>> yes
> >>>>>> yes yes 251 0
> >>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>> yes
> >>>>>> yes yes 252 0
> >>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>> yes
> >>>>>> yes yes 254 0
> >>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>> yes
> >>>>>> yes yes 255 0
> >>>>>> FJORTL+ProximaNova-Light CID Type 0C Identity-H
> >>>>> yes
> >>>>>> yes yes 165 0
> >>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>> yes
> >>>>>> yes yes 259 0
> >>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>> yes
> >>>>>> yes yes 260 0
> >>>>>>
> >>>>>> $pdffonts merged.pdf
> >>>>>> name type encoding
> >>>>> emb
> >>>>>> sub uni object ID
> >>>>>> ------------------------------------ -----------------
> >>> ----------------
> >>>>> ---
> >>>>>> --- --- ---------
> >>>>>> AYOVHV+Facit-Bold Type 1C Custom
> >>>>> yes
> >>>>>> yes yes 131 0
> >>>>>> AYOVHV+ProximaNova-Bold Type 1C Custom
> >>>>> yes
> >>>>>> yes yes 132 0
> >>>>>> AYOVHV+ProximaNova-Light Type 1C Custom
> >>>>> yes
> >>>>>> yes yes 133 0
> >>>>>> AYOVHV+ProximaNova-Semibold Type 1C WinAnsi
> >>>>> yes
> >>>>>> yes yes 134 0
> >>>>>> ProximaNova-Light Type 1C (OT) Custom
> >>>>> yes
> >>>>>> no no 9 0
> >>>>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
> >>>>> yes
> >>>>>> yes no 192 0
> >>>>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
> >>>>> yes
> >>>>>> yes no 193 0
> >>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
> >>>>> yes
> >>>>>> yes yes 275 0
> >>>>>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
> >>>>>> yes yes yes 276 0*
> >>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
> >>>>> yes
> >>>>>> yes yes 277 0
> >>>>>> MHGLSX+Facit-Bold Type 1C Custom
> >>>>> yes
> >>>>>> yes yes 278 0
> >>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>> yes
> >>>>>> yes yes 437 0
> >>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>> yes
> >>>>>> yes yes 438 0
> >>>>>> ProximaNova-Bold Type 1C (OT) Custom
> >>>>> yes
> >>>>>> no no 462 0
> >>>>>> ProximaNova-Light Type 1C (OT) Custom
> >>>>> yes
> >>>>>> no no 512 0
> >>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>> yes
> >>>>>> yes yes 500 0
> >>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>> yes
> >>>>>> yes yes 501 0
> >>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>> yes
> >>>>>> yes yes 503 0
> >>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>> yes
> >>>>>> yes yes 504 0
> >>>>>> FJORTL+ProximaNova-Light CID Type 0C Identity-H
> >>>>> yes
> >>>>>> yes yes 377 0
> >>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >>>>> yes
> >>>>>> yes yes 451 0
> >>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >>>>> yes
> >>>>>> yes yes 452 0
> >>>>>>
> >>>>>> Why are the field values not showing up and how can I fix that?
> >>>>>>
> >>>>>> Thanks for your help!
> >>>>>>
> >>>>>> Johannes
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> >>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> >>> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
>
Re: Weird issue with fonts in input fields after merging
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi,
> Am 08.10.2015 um 16:31 schrieb Johannes Barre <jo...@billfront.com>:
>
> Hello!
>
> I just tried the 2.0 snapshot from yesterday and get this error:
>
> org/apache/pdfbox/pdmodel/font/PDType1CFont.java:283:in `encode':
> java.lang.UnsupportedOperationException: Not implemented: Type1C
there is already a ticket for that.
BR Maruan
>
> Is that also true for 1.8.10 (just without the error) and could it be
> related to the problem?
>
> Greets, Johannes
>
> PS: I've also pushed a Java version of my code to the gist. It's probably
> as messy as my JRuby version, they're just experiments.
>
> On Thu, Oct 8, 2015 at 3:41 PM, Johannes Barre <johannes.barre@billfront.com
>> wrote:
>
>> Hello Maruan!
>>
>> Thank again. I hope my last answer didn't sounded too aggressive (written
>> communication is difficult). I'm grateful for any help!
>>
>> You brought up a good point, as a Linux user I've only checked with Google
>> Chrome & xpdf (and I was referring to the xpdf). In the Acrobat Reader 9
>> (Linux) and XI (Win XP), the field values are not shown. So I got a new
>> problem :'(
>>
>> Greets, Johannes
>>
>> On Thu, Oct 8, 2015 at 3:00 PM, Maruan Sahyoun <sa...@fileaffairs.de>
>> wrote:
>>
>>> Hi,
>>>
>>>>> Am 08.10.2015 um 14:53 schrieb Johannes Barre <
>>>> johannes.barre@billfront.com>:
>>>>
>>>> Hello Maruan!
>>>>
>>>> Thank you for your reply.
>>>>
>>>> So, basically you say, the source PDFs aren't valid already? I've asked
>>> and
>>>> they were created with Adobe InDesign, I would hope that Adobe knows
>>> how to
>>>> generate valid PDFs. :-/
>>>
>>> the PDFs are not invalid - that's not what I wanted to say.
>>>
>>>> But even so, why is everything looking good when I just fill in the
>>> fields
>>>> without merging it? It has the same issue with the fonts name and I
>>> filled
>>>> the field with the same method.
>>>
>>> when you say looking good - are you looking at it with Adobe Reader or
>>> XPDF or ….
>>>
>>> I can have a more in-depth look tonight - my comments were about the
>>> quick observations I made.
>>>
>>> BR
>>> Maruan
>>>
>>>> Greets, Johannes
>>>>
>>>> On Thu, Oct 8, 2015 at 2:35 PM, Maruan Sahyoun <sa...@fileaffairs.de>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>>> Am 08.10.2015 um 13:30 schrieb Johannes Barre <
>>>>>> johannes.barre@billfront.com>:
>>>>>>
>>>>>> Hello!
>>>>>>
>>>>>> I have a weird issue. So, I have to PDFs. When I fill form fields in
>>> one
>>>>> of
>>>>>> them and save, everything looks fine. However, when I append this
>>> filled
>>>>>> PDF to another one, xpdf doesn't display the values anymore and
>>> complains
>>>>>> about missing fonts:
>>>>>>
>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
>>>>>> Syntax Error: Unknown font in field's DA string
>>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
>>>>>> Syntax Error: Unknown font in field's DA string
>>>>>>
>>>>>> I'm using JRuby (9k), but I hope it's understandable for you. I put
>>> the
>>>>>> source & PDFs in this gist:
>>>>>> https://gist.github.com/iGEL/a8484f0bc44b03fa9de1 (Will delete it
>>> later,
>>>>>> once the issue is solved)
>>>>>>
>>>>>> Other specs: pdfbox-app-1.8.10, openjdk 1.8.0_66, Debian Jessy inside
>>> of
>>>>>> Docker
>>>>>>
>>>>>> As you can see, I use a special way to set the values. I had problems
>>>>> with
>>>>>> German umlauts using setValue and it also sometimes fails (Possibly
>>>>> related
>>>>>> to https://issues.apache.org/jira/browse/PDFBOX-1550, the message is
>>> the
>>>>>> same as in that bug)
>>>>>
>>>>> setting the field value directly using
>>>>>
>>>>> form.getField(name).getDictionary.setItem(
>>>>> Java::OrgApachePdfboxCos::COSName::V,
>>>>> Java::OrgApachePdfboxCos::COSString.new(value)
>>>>> )
>>>>>
>>>>> will not update the visual appearance of the filed and as a result the
>>>>> newly set value is not visible
>>>>>
>>>>>
>>>>>> The COVER_PAGE.pdf and BIW_FORM.pdf are the templates I'm using,
>>>>>> form_filled.pdf is just the BIW_FORM.pdf with 2 fields filled and
>>> merged
>>>>> is
>>>>>> COVER_PAGE.pdf and form_filled.pdf merged together.
>>>>>>
>>>>>> The p in line 15 and 22 print out the DA value of the field and it's
>>> the
>>>>>> same for both files:
>>>>>>
>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # form_filled.pdf
>>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # merged.pdf
>>>>>
>>>>> the font resource is called /ProximaNova-Regular but that's not in your
>>>>> PDF as the font which is in your PDF is called
>>> /MHGLSX+ProximaNova-Regular.
>>>>> In addition the issue with a font subset is that only certain
>>> characters
>>>>> are part of that subset. As a result some of the characters you need to
>>>>> display your field value might not be within the subset.
>>>>>
>>>>> BR
>>>>> Maruan
>>>>>
>>>>>
>>>>>>
>>>>>> This font is according to pdffonts in both files:
>>>>>>
>>>>>> $ pdffonts form_filled.pdf
>>>>>> name type encoding
>>>>> emb
>>>>>> sub uni object ID
>>>>>> ------------------------------------ -----------------
>>> ----------------
>>>>> ---
>>>>>> --- --- ---------
>>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
>>>>> yes
>>>>>> yes yes 124 0
>>>>>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
>>>>>> yes yes yes 125 0*
>>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
>>>>> yes
>>>>>> yes yes 126 0
>>>>>> MHGLSX+Facit-Bold Type 1C Custom
>>>>> yes
>>>>>> yes yes 127 0
>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>> yes
>>>>>> yes yes 218 0
>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>> yes
>>>>>> yes yes 219 0
>>>>>> ProximaNova-Bold Type 1C (OT) Custom
>>>>> yes
>>>>>> no no 8 0
>>>>>> ProximaNova-Light Type 1C (OT) Custom
>>>>> yes
>>>>>> no no 9 0
>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>> yes
>>>>>> yes yes 251 0
>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>> yes
>>>>>> yes yes 252 0
>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>> yes
>>>>>> yes yes 254 0
>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>> yes
>>>>>> yes yes 255 0
>>>>>> FJORTL+ProximaNova-Light CID Type 0C Identity-H
>>>>> yes
>>>>>> yes yes 165 0
>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>> yes
>>>>>> yes yes 259 0
>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>> yes
>>>>>> yes yes 260 0
>>>>>>
>>>>>> $pdffonts merged.pdf
>>>>>> name type encoding
>>>>> emb
>>>>>> sub uni object ID
>>>>>> ------------------------------------ -----------------
>>> ----------------
>>>>> ---
>>>>>> --- --- ---------
>>>>>> AYOVHV+Facit-Bold Type 1C Custom
>>>>> yes
>>>>>> yes yes 131 0
>>>>>> AYOVHV+ProximaNova-Bold Type 1C Custom
>>>>> yes
>>>>>> yes yes 132 0
>>>>>> AYOVHV+ProximaNova-Light Type 1C Custom
>>>>> yes
>>>>>> yes yes 133 0
>>>>>> AYOVHV+ProximaNova-Semibold Type 1C WinAnsi
>>>>> yes
>>>>>> yes yes 134 0
>>>>>> ProximaNova-Light Type 1C (OT) Custom
>>>>> yes
>>>>>> no no 9 0
>>>>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
>>>>> yes
>>>>>> yes no 192 0
>>>>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
>>>>> yes
>>>>>> yes no 193 0
>>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
>>>>> yes
>>>>>> yes yes 275 0
>>>>>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
>>>>>> yes yes yes 276 0*
>>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
>>>>> yes
>>>>>> yes yes 277 0
>>>>>> MHGLSX+Facit-Bold Type 1C Custom
>>>>> yes
>>>>>> yes yes 278 0
>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>> yes
>>>>>> yes yes 437 0
>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>> yes
>>>>>> yes yes 438 0
>>>>>> ProximaNova-Bold Type 1C (OT) Custom
>>>>> yes
>>>>>> no no 462 0
>>>>>> ProximaNova-Light Type 1C (OT) Custom
>>>>> yes
>>>>>> no no 512 0
>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>> yes
>>>>>> yes yes 500 0
>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>> yes
>>>>>> yes yes 501 0
>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>> yes
>>>>>> yes yes 503 0
>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>> yes
>>>>>> yes yes 504 0
>>>>>> FJORTL+ProximaNova-Light CID Type 0C Identity-H
>>>>> yes
>>>>>> yes yes 377 0
>>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>>> yes
>>>>>> yes yes 451 0
>>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>>> yes
>>>>>> yes yes 452 0
>>>>>>
>>>>>> Why are the field values not showing up and how can I fix that?
>>>>>>
>>>>>> Thanks for your help!
>>>>>>
>>>>>> Johannes
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Weird issue with fonts in input fields after merging
Posted by Johannes Barre <jo...@billfront.com>.
Hello!
I just tried the 2.0 snapshot from yesterday and get this error:
org/apache/pdfbox/pdmodel/font/PDType1CFont.java:283:in `encode':
java.lang.UnsupportedOperationException: Not implemented: Type1C
Is that also true for 1.8.10 (just without the error) and could it be
related to the problem?
Greets, Johannes
PS: I've also pushed a Java version of my code to the gist. It's probably
as messy as my JRuby version, they're just experiments.
On Thu, Oct 8, 2015 at 3:41 PM, Johannes Barre <johannes.barre@billfront.com
> wrote:
> Hello Maruan!
>
> Thank again. I hope my last answer didn't sounded too aggressive (written
> communication is difficult). I'm grateful for any help!
>
> You brought up a good point, as a Linux user I've only checked with Google
> Chrome & xpdf (and I was referring to the xpdf). In the Acrobat Reader 9
> (Linux) and XI (Win XP), the field values are not shown. So I got a new
> problem :'(
>
> Greets, Johannes
>
> On Thu, Oct 8, 2015 at 3:00 PM, Maruan Sahyoun <sa...@fileaffairs.de>
> wrote:
>
>> Hi,
>>
>> > Am 08.10.2015 um 14:53 schrieb Johannes Barre <
>> johannes.barre@billfront.com>:
>> >
>> > Hello Maruan!
>> >
>> > Thank you for your reply.
>> >
>> > So, basically you say, the source PDFs aren't valid already? I've asked
>> and
>> > they were created with Adobe InDesign, I would hope that Adobe knows
>> how to
>> > generate valid PDFs. :-/
>> >
>>
>> the PDFs are not invalid - that's not what I wanted to say.
>>
>> > But even so, why is everything looking good when I just fill in the
>> fields
>> > without merging it? It has the same issue with the fonts name and I
>> filled
>> > the field with the same method.
>> >
>>
>> when you say looking good - are you looking at it with Adobe Reader or
>> XPDF or ….
>>
>> I can have a more in-depth look tonight - my comments were about the
>> quick observations I made.
>>
>> BR
>> Maruan
>>
>> > Greets, Johannes
>> >
>> > On Thu, Oct 8, 2015 at 2:35 PM, Maruan Sahyoun <sa...@fileaffairs.de>
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >>> Am 08.10.2015 um 13:30 schrieb Johannes Barre <
>> >> johannes.barre@billfront.com>:
>> >>>
>> >>> Hello!
>> >>>
>> >>> I have a weird issue. So, I have to PDFs. When I fill form fields in
>> one
>> >> of
>> >>> them and save, everything looks fine. However, when I append this
>> filled
>> >>> PDF to another one, xpdf doesn't display the values anymore and
>> complains
>> >>> about missing fonts:
>> >>>
>> >>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
>> >>> Syntax Error: Unknown font in field's DA string
>> >>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
>> >>> Syntax Error: Unknown font in field's DA string
>> >>>
>> >>> I'm using JRuby (9k), but I hope it's understandable for you. I put
>> the
>> >>> source & PDFs in this gist:
>> >>> https://gist.github.com/iGEL/a8484f0bc44b03fa9de1 (Will delete it
>> later,
>> >>> once the issue is solved)
>> >>>
>> >>> Other specs: pdfbox-app-1.8.10, openjdk 1.8.0_66, Debian Jessy inside
>> of
>> >>> Docker
>> >>>
>> >>> As you can see, I use a special way to set the values. I had problems
>> >> with
>> >>> German umlauts using setValue and it also sometimes fails (Possibly
>> >> related
>> >>> to https://issues.apache.org/jira/browse/PDFBOX-1550, the message is
>> the
>> >>> same as in that bug)
>> >>>
>> >>
>> >> setting the field value directly using
>> >>
>> >> form.getField(name).getDictionary.setItem(
>> >> Java::OrgApachePdfboxCos::COSName::V,
>> >> Java::OrgApachePdfboxCos::COSString.new(value)
>> >> )
>> >>
>> >> will not update the visual appearance of the filed and as a result the
>> >> newly set value is not visible
>> >>
>> >>
>> >>> The COVER_PAGE.pdf and BIW_FORM.pdf are the templates I'm using,
>> >>> form_filled.pdf is just the BIW_FORM.pdf with 2 fields filled and
>> merged
>> >> is
>> >>> COVER_PAGE.pdf and form_filled.pdf merged together.
>> >>>
>> >>> The p in line 15 and 22 print out the DA value of the field and it's
>> the
>> >>> same for both files:
>> >>>
>> >>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # form_filled.pdf
>> >>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # merged.pdf
>> >>
>> >> the font resource is called /ProximaNova-Regular but that's not in your
>> >> PDF as the font which is in your PDF is called
>> /MHGLSX+ProximaNova-Regular.
>> >> In addition the issue with a font subset is that only certain
>> characters
>> >> are part of that subset. As a result some of the characters you need to
>> >> display your field value might not be within the subset.
>> >>
>> >> BR
>> >> Maruan
>> >>
>> >>
>> >>>
>> >>> This font is according to pdffonts in both files:
>> >>>
>> >>> $ pdffonts form_filled.pdf
>> >>> name type encoding
>> >> emb
>> >>> sub uni object ID
>> >>> ------------------------------------ -----------------
>> ----------------
>> >> ---
>> >>> --- --- ---------
>> >>> NPQRGV+ProximaNova-Light Type 1C Custom
>> >> yes
>> >>> yes yes 124 0
>> >>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
>> >>> yes yes yes 125 0*
>> >>> NPQRGV+ProximaNova-Bold Type 1C Custom
>> >> yes
>> >>> yes yes 126 0
>> >>> MHGLSX+Facit-Bold Type 1C Custom
>> >> yes
>> >>> yes yes 127 0
>> >>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>> >> yes
>> >>> yes yes 218 0
>> >>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>> >> yes
>> >>> yes yes 219 0
>> >>> ProximaNova-Bold Type 1C (OT) Custom
>> >> yes
>> >>> no no 8 0
>> >>> ProximaNova-Light Type 1C (OT) Custom
>> >> yes
>> >>> no no 9 0
>> >>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>> >> yes
>> >>> yes yes 251 0
>> >>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>> >> yes
>> >>> yes yes 252 0
>> >>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>> >> yes
>> >>> yes yes 254 0
>> >>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>> >> yes
>> >>> yes yes 255 0
>> >>> FJORTL+ProximaNova-Light CID Type 0C Identity-H
>> >> yes
>> >>> yes yes 165 0
>> >>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>> >> yes
>> >>> yes yes 259 0
>> >>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>> >> yes
>> >>> yes yes 260 0
>> >>>
>> >>> $pdffonts merged.pdf
>> >>> name type encoding
>> >> emb
>> >>> sub uni object ID
>> >>> ------------------------------------ -----------------
>> ----------------
>> >> ---
>> >>> --- --- ---------
>> >>> AYOVHV+Facit-Bold Type 1C Custom
>> >> yes
>> >>> yes yes 131 0
>> >>> AYOVHV+ProximaNova-Bold Type 1C Custom
>> >> yes
>> >>> yes yes 132 0
>> >>> AYOVHV+ProximaNova-Light Type 1C Custom
>> >> yes
>> >>> yes yes 133 0
>> >>> AYOVHV+ProximaNova-Semibold Type 1C WinAnsi
>> >> yes
>> >>> yes yes 134 0
>> >>> ProximaNova-Light Type 1C (OT) Custom
>> >> yes
>> >>> no no 9 0
>> >>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
>> >> yes
>> >>> yes no 192 0
>> >>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
>> >> yes
>> >>> yes no 193 0
>> >>> NPQRGV+ProximaNova-Light Type 1C Custom
>> >> yes
>> >>> yes yes 275 0
>> >>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
>> >>> yes yes yes 276 0*
>> >>> NPQRGV+ProximaNova-Bold Type 1C Custom
>> >> yes
>> >>> yes yes 277 0
>> >>> MHGLSX+Facit-Bold Type 1C Custom
>> >> yes
>> >>> yes yes 278 0
>> >>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>> >> yes
>> >>> yes yes 437 0
>> >>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>> >> yes
>> >>> yes yes 438 0
>> >>> ProximaNova-Bold Type 1C (OT) Custom
>> >> yes
>> >>> no no 462 0
>> >>> ProximaNova-Light Type 1C (OT) Custom
>> >> yes
>> >>> no no 512 0
>> >>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>> >> yes
>> >>> yes yes 500 0
>> >>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>> >> yes
>> >>> yes yes 501 0
>> >>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>> >> yes
>> >>> yes yes 503 0
>> >>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>> >> yes
>> >>> yes yes 504 0
>> >>> FJORTL+ProximaNova-Light CID Type 0C Identity-H
>> >> yes
>> >>> yes yes 377 0
>> >>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>> >> yes
>> >>> yes yes 451 0
>> >>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>> >> yes
>> >>> yes yes 452 0
>> >>>
>> >>> Why are the field values not showing up and how can I fix that?
>> >>>
>> >>> Thanks for your help!
>> >>>
>> >>> Johannes
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> >> For additional commands, e-mail: users-help@pdfbox.apache.org
>> >>
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>>
>
Re: Weird issue with fonts in input fields after merging
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi,
> Am 08.10.2015 um 15:41 schrieb Johannes Barre <jo...@billfront.com>:
>
> Hello Maruan!
>
> Thank again. I hope my last answer didn't sounded too aggressive (written
> communication is difficult). I'm grateful for any help!
No, it didn't
>
> You brought up a good point, as a Linux user I've only checked with Google
> Chrome & xpdf (and I was referring to the xpdf). In the Acrobat Reader 9
> (Linux) and XI (Win XP), the field values are not shown. So I got a new
> problem :'(
If possible, give PDFBox 2.0.0 a try e.g. PDTextField.setValue(String value).
It should support all characters (as long as your font has them) and create the appearance for you so the value shows up in Adobe Reader.
BR Maruan
>
> Greets, Johannes
>
> On Thu, Oct 8, 2015 at 3:00 PM, Maruan Sahyoun <sa...@fileaffairs.de>
> wrote:
>
>> Hi,
>>
>>>> Am 08.10.2015 um 14:53 schrieb Johannes Barre <
>>> johannes.barre@billfront.com>:
>>>
>>> Hello Maruan!
>>>
>>> Thank you for your reply.
>>>
>>> So, basically you say, the source PDFs aren't valid already? I've asked
>> and
>>> they were created with Adobe InDesign, I would hope that Adobe knows how
>> to
>>> generate valid PDFs. :-/
>>
>> the PDFs are not invalid - that's not what I wanted to say.
>>
>>> But even so, why is everything looking good when I just fill in the
>> fields
>>> without merging it? It has the same issue with the fonts name and I
>> filled
>>> the field with the same method.
>>
>> when you say looking good - are you looking at it with Adobe Reader or
>> XPDF or ….
>>
>> I can have a more in-depth look tonight - my comments were about the quick
>> observations I made.
>>
>> BR
>> Maruan
>>
>>> Greets, Johannes
>>>
>>> On Thu, Oct 8, 2015 at 2:35 PM, Maruan Sahyoun <sa...@fileaffairs.de>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>>>> Am 08.10.2015 um 13:30 schrieb Johannes Barre <
>>>>> johannes.barre@billfront.com>:
>>>>>
>>>>> Hello!
>>>>>
>>>>> I have a weird issue. So, I have to PDFs. When I fill form fields in
>> one
>>>> of
>>>>> them and save, everything looks fine. However, when I append this
>> filled
>>>>> PDF to another one, xpdf doesn't display the values anymore and
>> complains
>>>>> about missing fonts:
>>>>>
>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
>>>>> Syntax Error: Unknown font in field's DA string
>>>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
>>>>> Syntax Error: Unknown font in field's DA string
>>>>>
>>>>> I'm using JRuby (9k), but I hope it's understandable for you. I put the
>>>>> source & PDFs in this gist:
>>>>> https://gist.github.com/iGEL/a8484f0bc44b03fa9de1 (Will delete it
>> later,
>>>>> once the issue is solved)
>>>>>
>>>>> Other specs: pdfbox-app-1.8.10, openjdk 1.8.0_66, Debian Jessy inside
>> of
>>>>> Docker
>>>>>
>>>>> As you can see, I use a special way to set the values. I had problems
>>>> with
>>>>> German umlauts using setValue and it also sometimes fails (Possibly
>>>> related
>>>>> to https://issues.apache.org/jira/browse/PDFBOX-1550, the message is
>> the
>>>>> same as in that bug)
>>>>
>>>> setting the field value directly using
>>>>
>>>> form.getField(name).getDictionary.setItem(
>>>> Java::OrgApachePdfboxCos::COSName::V,
>>>> Java::OrgApachePdfboxCos::COSString.new(value)
>>>> )
>>>>
>>>> will not update the visual appearance of the filed and as a result the
>>>> newly set value is not visible
>>>>
>>>>
>>>>> The COVER_PAGE.pdf and BIW_FORM.pdf are the templates I'm using,
>>>>> form_filled.pdf is just the BIW_FORM.pdf with 2 fields filled and
>> merged
>>>> is
>>>>> COVER_PAGE.pdf and form_filled.pdf merged together.
>>>>>
>>>>> The p in line 15 and 22 print out the DA value of the field and it's
>> the
>>>>> same for both files:
>>>>>
>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # form_filled.pdf
>>>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # merged.pdf
>>>>
>>>> the font resource is called /ProximaNova-Regular but that's not in your
>>>> PDF as the font which is in your PDF is called
>> /MHGLSX+ProximaNova-Regular.
>>>> In addition the issue with a font subset is that only certain characters
>>>> are part of that subset. As a result some of the characters you need to
>>>> display your field value might not be within the subset.
>>>>
>>>> BR
>>>> Maruan
>>>>
>>>>
>>>>>
>>>>> This font is according to pdffonts in both files:
>>>>>
>>>>> $ pdffonts form_filled.pdf
>>>>> name type encoding
>>>> emb
>>>>> sub uni object ID
>>>>> ------------------------------------ ----------------- ----------------
>>>> ---
>>>>> --- --- ---------
>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
>>>> yes
>>>>> yes yes 124 0
>>>>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
>>>>> yes yes yes 125 0*
>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
>>>> yes
>>>>> yes yes 126 0
>>>>> MHGLSX+Facit-Bold Type 1C Custom
>>>> yes
>>>>> yes yes 127 0
>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>> yes
>>>>> yes yes 218 0
>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>> yes
>>>>> yes yes 219 0
>>>>> ProximaNova-Bold Type 1C (OT) Custom
>>>> yes
>>>>> no no 8 0
>>>>> ProximaNova-Light Type 1C (OT) Custom
>>>> yes
>>>>> no no 9 0
>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>> yes
>>>>> yes yes 251 0
>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>> yes
>>>>> yes yes 252 0
>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>> yes
>>>>> yes yes 254 0
>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>> yes
>>>>> yes yes 255 0
>>>>> FJORTL+ProximaNova-Light CID Type 0C Identity-H
>>>> yes
>>>>> yes yes 165 0
>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>> yes
>>>>> yes yes 259 0
>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>> yes
>>>>> yes yes 260 0
>>>>>
>>>>> $pdffonts merged.pdf
>>>>> name type encoding
>>>> emb
>>>>> sub uni object ID
>>>>> ------------------------------------ ----------------- ----------------
>>>> ---
>>>>> --- --- ---------
>>>>> AYOVHV+Facit-Bold Type 1C Custom
>>>> yes
>>>>> yes yes 131 0
>>>>> AYOVHV+ProximaNova-Bold Type 1C Custom
>>>> yes
>>>>> yes yes 132 0
>>>>> AYOVHV+ProximaNova-Light Type 1C Custom
>>>> yes
>>>>> yes yes 133 0
>>>>> AYOVHV+ProximaNova-Semibold Type 1C WinAnsi
>>>> yes
>>>>> yes yes 134 0
>>>>> ProximaNova-Light Type 1C (OT) Custom
>>>> yes
>>>>> no no 9 0
>>>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
>>>> yes
>>>>> yes no 192 0
>>>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
>>>> yes
>>>>> yes no 193 0
>>>>> NPQRGV+ProximaNova-Light Type 1C Custom
>>>> yes
>>>>> yes yes 275 0
>>>>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
>>>>> yes yes yes 276 0*
>>>>> NPQRGV+ProximaNova-Bold Type 1C Custom
>>>> yes
>>>>> yes yes 277 0
>>>>> MHGLSX+Facit-Bold Type 1C Custom
>>>> yes
>>>>> yes yes 278 0
>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>> yes
>>>>> yes yes 437 0
>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>> yes
>>>>> yes yes 438 0
>>>>> ProximaNova-Bold Type 1C (OT) Custom
>>>> yes
>>>>> no no 462 0
>>>>> ProximaNova-Light Type 1C (OT) Custom
>>>> yes
>>>>> no no 512 0
>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>> yes
>>>>> yes yes 500 0
>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>> yes
>>>>> yes yes 501 0
>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>> yes
>>>>> yes yes 503 0
>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>> yes
>>>>> yes yes 504 0
>>>>> FJORTL+ProximaNova-Light CID Type 0C Identity-H
>>>> yes
>>>>> yes yes 377 0
>>>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>>>> yes
>>>>> yes yes 451 0
>>>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>>>> yes
>>>>> yes yes 452 0
>>>>>
>>>>> Why are the field values not showing up and how can I fix that?
>>>>>
>>>>> Thanks for your help!
>>>>>
>>>>> Johannes
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>>>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Weird issue with fonts in input fields after merging
Posted by Johannes Barre <jo...@billfront.com>.
Hello Maruan!
Thank again. I hope my last answer didn't sounded too aggressive (written
communication is difficult). I'm grateful for any help!
You brought up a good point, as a Linux user I've only checked with Google
Chrome & xpdf (and I was referring to the xpdf). In the Acrobat Reader 9
(Linux) and XI (Win XP), the field values are not shown. So I got a new
problem :'(
Greets, Johannes
On Thu, Oct 8, 2015 at 3:00 PM, Maruan Sahyoun <sa...@fileaffairs.de>
wrote:
> Hi,
>
> > Am 08.10.2015 um 14:53 schrieb Johannes Barre <
> johannes.barre@billfront.com>:
> >
> > Hello Maruan!
> >
> > Thank you for your reply.
> >
> > So, basically you say, the source PDFs aren't valid already? I've asked
> and
> > they were created with Adobe InDesign, I would hope that Adobe knows how
> to
> > generate valid PDFs. :-/
> >
>
> the PDFs are not invalid - that's not what I wanted to say.
>
> > But even so, why is everything looking good when I just fill in the
> fields
> > without merging it? It has the same issue with the fonts name and I
> filled
> > the field with the same method.
> >
>
> when you say looking good - are you looking at it with Adobe Reader or
> XPDF or ….
>
> I can have a more in-depth look tonight - my comments were about the quick
> observations I made.
>
> BR
> Maruan
>
> > Greets, Johannes
> >
> > On Thu, Oct 8, 2015 at 2:35 PM, Maruan Sahyoun <sa...@fileaffairs.de>
> > wrote:
> >
> >> Hi,
> >>
> >>> Am 08.10.2015 um 13:30 schrieb Johannes Barre <
> >> johannes.barre@billfront.com>:
> >>>
> >>> Hello!
> >>>
> >>> I have a weird issue. So, I have to PDFs. When I fill form fields in
> one
> >> of
> >>> them and save, everything looks fine. However, when I append this
> filled
> >>> PDF to another one, xpdf doesn't display the values anymore and
> complains
> >>> about missing fonts:
> >>>
> >>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
> >>> Syntax Error: Unknown font in field's DA string
> >>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
> >>> Syntax Error: Unknown font in field's DA string
> >>>
> >>> I'm using JRuby (9k), but I hope it's understandable for you. I put the
> >>> source & PDFs in this gist:
> >>> https://gist.github.com/iGEL/a8484f0bc44b03fa9de1 (Will delete it
> later,
> >>> once the issue is solved)
> >>>
> >>> Other specs: pdfbox-app-1.8.10, openjdk 1.8.0_66, Debian Jessy inside
> of
> >>> Docker
> >>>
> >>> As you can see, I use a special way to set the values. I had problems
> >> with
> >>> German umlauts using setValue and it also sometimes fails (Possibly
> >> related
> >>> to https://issues.apache.org/jira/browse/PDFBOX-1550, the message is
> the
> >>> same as in that bug)
> >>>
> >>
> >> setting the field value directly using
> >>
> >> form.getField(name).getDictionary.setItem(
> >> Java::OrgApachePdfboxCos::COSName::V,
> >> Java::OrgApachePdfboxCos::COSString.new(value)
> >> )
> >>
> >> will not update the visual appearance of the filed and as a result the
> >> newly set value is not visible
> >>
> >>
> >>> The COVER_PAGE.pdf and BIW_FORM.pdf are the templates I'm using,
> >>> form_filled.pdf is just the BIW_FORM.pdf with 2 fields filled and
> merged
> >> is
> >>> COVER_PAGE.pdf and form_filled.pdf merged together.
> >>>
> >>> The p in line 15 and 22 print out the DA value of the field and it's
> the
> >>> same for both files:
> >>>
> >>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # form_filled.pdf
> >>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # merged.pdf
> >>
> >> the font resource is called /ProximaNova-Regular but that's not in your
> >> PDF as the font which is in your PDF is called
> /MHGLSX+ProximaNova-Regular.
> >> In addition the issue with a font subset is that only certain characters
> >> are part of that subset. As a result some of the characters you need to
> >> display your field value might not be within the subset.
> >>
> >> BR
> >> Maruan
> >>
> >>
> >>>
> >>> This font is according to pdffonts in both files:
> >>>
> >>> $ pdffonts form_filled.pdf
> >>> name type encoding
> >> emb
> >>> sub uni object ID
> >>> ------------------------------------ ----------------- ----------------
> >> ---
> >>> --- --- ---------
> >>> NPQRGV+ProximaNova-Light Type 1C Custom
> >> yes
> >>> yes yes 124 0
> >>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
> >>> yes yes yes 125 0*
> >>> NPQRGV+ProximaNova-Bold Type 1C Custom
> >> yes
> >>> yes yes 126 0
> >>> MHGLSX+Facit-Bold Type 1C Custom
> >> yes
> >>> yes yes 127 0
> >>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >> yes
> >>> yes yes 218 0
> >>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >> yes
> >>> yes yes 219 0
> >>> ProximaNova-Bold Type 1C (OT) Custom
> >> yes
> >>> no no 8 0
> >>> ProximaNova-Light Type 1C (OT) Custom
> >> yes
> >>> no no 9 0
> >>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >> yes
> >>> yes yes 251 0
> >>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >> yes
> >>> yes yes 252 0
> >>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >> yes
> >>> yes yes 254 0
> >>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >> yes
> >>> yes yes 255 0
> >>> FJORTL+ProximaNova-Light CID Type 0C Identity-H
> >> yes
> >>> yes yes 165 0
> >>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >> yes
> >>> yes yes 259 0
> >>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >> yes
> >>> yes yes 260 0
> >>>
> >>> $pdffonts merged.pdf
> >>> name type encoding
> >> emb
> >>> sub uni object ID
> >>> ------------------------------------ ----------------- ----------------
> >> ---
> >>> --- --- ---------
> >>> AYOVHV+Facit-Bold Type 1C Custom
> >> yes
> >>> yes yes 131 0
> >>> AYOVHV+ProximaNova-Bold Type 1C Custom
> >> yes
> >>> yes yes 132 0
> >>> AYOVHV+ProximaNova-Light Type 1C Custom
> >> yes
> >>> yes yes 133 0
> >>> AYOVHV+ProximaNova-Semibold Type 1C WinAnsi
> >> yes
> >>> yes yes 134 0
> >>> ProximaNova-Light Type 1C (OT) Custom
> >> yes
> >>> no no 9 0
> >>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
> >> yes
> >>> yes no 192 0
> >>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
> >> yes
> >>> yes no 193 0
> >>> NPQRGV+ProximaNova-Light Type 1C Custom
> >> yes
> >>> yes yes 275 0
> >>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
> >>> yes yes yes 276 0*
> >>> NPQRGV+ProximaNova-Bold Type 1C Custom
> >> yes
> >>> yes yes 277 0
> >>> MHGLSX+Facit-Bold Type 1C Custom
> >> yes
> >>> yes yes 278 0
> >>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >> yes
> >>> yes yes 437 0
> >>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >> yes
> >>> yes yes 438 0
> >>> ProximaNova-Bold Type 1C (OT) Custom
> >> yes
> >>> no no 462 0
> >>> ProximaNova-Light Type 1C (OT) Custom
> >> yes
> >>> no no 512 0
> >>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >> yes
> >>> yes yes 500 0
> >>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >> yes
> >>> yes yes 501 0
> >>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >> yes
> >>> yes yes 503 0
> >>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >> yes
> >>> yes yes 504 0
> >>> FJORTL+ProximaNova-Light CID Type 0C Identity-H
> >> yes
> >>> yes yes 377 0
> >>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> >> yes
> >>> yes yes 451 0
> >>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
> >> yes
> >>> yes yes 452 0
> >>>
> >>> Why are the field values not showing up and how can I fix that?
> >>>
> >>> Thanks for your help!
> >>>
> >>> Johannes
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> >> For additional commands, e-mail: users-help@pdfbox.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
>
Re: Weird issue with fonts in input fields after merging
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi,
> Am 08.10.2015 um 14:53 schrieb Johannes Barre <jo...@billfront.com>:
>
> Hello Maruan!
>
> Thank you for your reply.
>
> So, basically you say, the source PDFs aren't valid already? I've asked and
> they were created with Adobe InDesign, I would hope that Adobe knows how to
> generate valid PDFs. :-/
>
the PDFs are not invalid - that's not what I wanted to say.
> But even so, why is everything looking good when I just fill in the fields
> without merging it? It has the same issue with the fonts name and I filled
> the field with the same method.
>
when you say looking good - are you looking at it with Adobe Reader or XPDF or ….
I can have a more in-depth look tonight - my comments were about the quick observations I made.
BR
Maruan
> Greets, Johannes
>
> On Thu, Oct 8, 2015 at 2:35 PM, Maruan Sahyoun <sa...@fileaffairs.de>
> wrote:
>
>> Hi,
>>
>>> Am 08.10.2015 um 13:30 schrieb Johannes Barre <
>> johannes.barre@billfront.com>:
>>>
>>> Hello!
>>>
>>> I have a weird issue. So, I have to PDFs. When I fill form fields in one
>> of
>>> them and save, everything looks fine. However, when I append this filled
>>> PDF to another one, xpdf doesn't display the values anymore and complains
>>> about missing fonts:
>>>
>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
>>> Syntax Error: Unknown font in field's DA string
>>> Syntax Error: Unknown font tag 'ProximaNova-Regular'
>>> Syntax Error: Unknown font in field's DA string
>>>
>>> I'm using JRuby (9k), but I hope it's understandable for you. I put the
>>> source & PDFs in this gist:
>>> https://gist.github.com/iGEL/a8484f0bc44b03fa9de1 (Will delete it later,
>>> once the issue is solved)
>>>
>>> Other specs: pdfbox-app-1.8.10, openjdk 1.8.0_66, Debian Jessy inside of
>>> Docker
>>>
>>> As you can see, I use a special way to set the values. I had problems
>> with
>>> German umlauts using setValue and it also sometimes fails (Possibly
>> related
>>> to https://issues.apache.org/jira/browse/PDFBOX-1550, the message is the
>>> same as in that bug)
>>>
>>
>> setting the field value directly using
>>
>> form.getField(name).getDictionary.setItem(
>> Java::OrgApachePdfboxCos::COSName::V,
>> Java::OrgApachePdfboxCos::COSString.new(value)
>> )
>>
>> will not update the visual appearance of the filed and as a result the
>> newly set value is not visible
>>
>>
>>> The COVER_PAGE.pdf and BIW_FORM.pdf are the templates I'm using,
>>> form_filled.pdf is just the BIW_FORM.pdf with 2 fields filled and merged
>> is
>>> COVER_PAGE.pdf and form_filled.pdf merged together.
>>>
>>> The p in line 15 and 22 print out the DA value of the field and it's the
>>> same for both files:
>>>
>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # form_filled.pdf
>>> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # merged.pdf
>>
>> the font resource is called /ProximaNova-Regular but that's not in your
>> PDF as the font which is in your PDF is called /MHGLSX+ProximaNova-Regular.
>> In addition the issue with a font subset is that only certain characters
>> are part of that subset. As a result some of the characters you need to
>> display your field value might not be within the subset.
>>
>> BR
>> Maruan
>>
>>
>>>
>>> This font is according to pdffonts in both files:
>>>
>>> $ pdffonts form_filled.pdf
>>> name type encoding
>> emb
>>> sub uni object ID
>>> ------------------------------------ ----------------- ----------------
>> ---
>>> --- --- ---------
>>> NPQRGV+ProximaNova-Light Type 1C Custom
>> yes
>>> yes yes 124 0
>>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
>>> yes yes yes 125 0*
>>> NPQRGV+ProximaNova-Bold Type 1C Custom
>> yes
>>> yes yes 126 0
>>> MHGLSX+Facit-Bold Type 1C Custom
>> yes
>>> yes yes 127 0
>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>> yes
>>> yes yes 218 0
>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>> yes
>>> yes yes 219 0
>>> ProximaNova-Bold Type 1C (OT) Custom
>> yes
>>> no no 8 0
>>> ProximaNova-Light Type 1C (OT) Custom
>> yes
>>> no no 9 0
>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>> yes
>>> yes yes 251 0
>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>> yes
>>> yes yes 252 0
>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>> yes
>>> yes yes 254 0
>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>> yes
>>> yes yes 255 0
>>> FJORTL+ProximaNova-Light CID Type 0C Identity-H
>> yes
>>> yes yes 165 0
>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>> yes
>>> yes yes 259 0
>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>> yes
>>> yes yes 260 0
>>>
>>> $pdffonts merged.pdf
>>> name type encoding
>> emb
>>> sub uni object ID
>>> ------------------------------------ ----------------- ----------------
>> ---
>>> --- --- ---------
>>> AYOVHV+Facit-Bold Type 1C Custom
>> yes
>>> yes yes 131 0
>>> AYOVHV+ProximaNova-Bold Type 1C Custom
>> yes
>>> yes yes 132 0
>>> AYOVHV+ProximaNova-Light Type 1C Custom
>> yes
>>> yes yes 133 0
>>> AYOVHV+ProximaNova-Semibold Type 1C WinAnsi
>> yes
>>> yes yes 134 0
>>> ProximaNova-Light Type 1C (OT) Custom
>> yes
>>> no no 9 0
>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
>> yes
>>> yes no 192 0
>>> AYOVHV+ProximaNova-Light Type 1C WinAnsi
>> yes
>>> yes no 193 0
>>> NPQRGV+ProximaNova-Light Type 1C Custom
>> yes
>>> yes yes 275 0
>>> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
>>> yes yes yes 276 0*
>>> NPQRGV+ProximaNova-Bold Type 1C Custom
>> yes
>>> yes yes 277 0
>>> MHGLSX+Facit-Bold Type 1C Custom
>> yes
>>> yes yes 278 0
>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>> yes
>>> yes yes 437 0
>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>> yes
>>> yes yes 438 0
>>> ProximaNova-Bold Type 1C (OT) Custom
>> yes
>>> no no 462 0
>>> ProximaNova-Light Type 1C (OT) Custom
>> yes
>>> no no 512 0
>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>> yes
>>> yes yes 500 0
>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>> yes
>>> yes yes 501 0
>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>> yes
>>> yes yes 503 0
>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>> yes
>>> yes yes 504 0
>>> FJORTL+ProximaNova-Light CID Type 0C Identity-H
>> yes
>>> yes yes 377 0
>>> NPQRGV+ProximaNova-Bold Type 1C WinAnsi
>> yes
>>> yes yes 451 0
>>> NPQRGV+ProximaNova-Light Type 1C WinAnsi
>> yes
>>> yes yes 452 0
>>>
>>> Why are the field values not showing up and how can I fix that?
>>>
>>> Thanks for your help!
>>>
>>> Johannes
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
>> For additional commands, e-mail: users-help@pdfbox.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: Weird issue with fonts in input fields after merging
Posted by Johannes Barre <jo...@billfront.com>.
Hello Maruan!
Thank you for your reply.
So, basically you say, the source PDFs aren't valid already? I've asked and
they were created with Adobe InDesign, I would hope that Adobe knows how to
generate valid PDFs. :-/
But even so, why is everything looking good when I just fill in the fields
without merging it? It has the same issue with the fonts name and I filled
the field with the same method.
Greets, Johannes
On Thu, Oct 8, 2015 at 2:35 PM, Maruan Sahyoun <sa...@fileaffairs.de>
wrote:
> Hi,
>
> > Am 08.10.2015 um 13:30 schrieb Johannes Barre <
> johannes.barre@billfront.com>:
> >
> > Hello!
> >
> > I have a weird issue. So, I have to PDFs. When I fill form fields in one
> of
> > them and save, everything looks fine. However, when I append this filled
> > PDF to another one, xpdf doesn't display the values anymore and complains
> > about missing fonts:
> >
> > Syntax Error: Unknown font tag 'ProximaNova-Regular'
> > Syntax Error: Unknown font in field's DA string
> > Syntax Error: Unknown font tag 'ProximaNova-Regular'
> > Syntax Error: Unknown font in field's DA string
> >
> > I'm using JRuby (9k), but I hope it's understandable for you. I put the
> > source & PDFs in this gist:
> > https://gist.github.com/iGEL/a8484f0bc44b03fa9de1 (Will delete it later,
> > once the issue is solved)
> >
> > Other specs: pdfbox-app-1.8.10, openjdk 1.8.0_66, Debian Jessy inside of
> > Docker
> >
> > As you can see, I use a special way to set the values. I had problems
> with
> > German umlauts using setValue and it also sometimes fails (Possibly
> related
> > to https://issues.apache.org/jira/browse/PDFBOX-1550, the message is the
> > same as in that bug)
> >
>
> setting the field value directly using
>
> form.getField(name).getDictionary.setItem(
> Java::OrgApachePdfboxCos::COSName::V,
> Java::OrgApachePdfboxCos::COSString.new(value)
> )
>
> will not update the visual appearance of the filed and as a result the
> newly set value is not visible
>
>
> > The COVER_PAGE.pdf and BIW_FORM.pdf are the templates I'm using,
> > form_filled.pdf is just the BIW_FORM.pdf with 2 fields filled and merged
> is
> > COVER_PAGE.pdf and form_filled.pdf merged together.
> >
> > The p in line 15 and 22 print out the DA value of the field and it's the
> > same for both files:
> >
> > "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # form_filled.pdf
> > "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # merged.pdf
>
> the font resource is called /ProximaNova-Regular but that's not in your
> PDF as the font which is in your PDF is called /MHGLSX+ProximaNova-Regular.
> In addition the issue with a font subset is that only certain characters
> are part of that subset. As a result some of the characters you need to
> display your field value might not be within the subset.
>
> BR
> Maruan
>
>
> >
> > This font is according to pdffonts in both files:
> >
> > $ pdffonts form_filled.pdf
> > name type encoding
> emb
> > sub uni object ID
> > ------------------------------------ ----------------- ----------------
> ---
> > --- --- ---------
> > NPQRGV+ProximaNova-Light Type 1C Custom
> yes
> > yes yes 124 0
> > *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
> > yes yes yes 125 0*
> > NPQRGV+ProximaNova-Bold Type 1C Custom
> yes
> > yes yes 126 0
> > MHGLSX+Facit-Bold Type 1C Custom
> yes
> > yes yes 127 0
> > NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> yes
> > yes yes 218 0
> > NPQRGV+ProximaNova-Light Type 1C WinAnsi
> yes
> > yes yes 219 0
> > ProximaNova-Bold Type 1C (OT) Custom
> yes
> > no no 8 0
> > ProximaNova-Light Type 1C (OT) Custom
> yes
> > no no 9 0
> > NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> yes
> > yes yes 251 0
> > NPQRGV+ProximaNova-Light Type 1C WinAnsi
> yes
> > yes yes 252 0
> > NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> yes
> > yes yes 254 0
> > NPQRGV+ProximaNova-Light Type 1C WinAnsi
> yes
> > yes yes 255 0
> > FJORTL+ProximaNova-Light CID Type 0C Identity-H
> yes
> > yes yes 165 0
> > NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> yes
> > yes yes 259 0
> > NPQRGV+ProximaNova-Light Type 1C WinAnsi
> yes
> > yes yes 260 0
> >
> > $pdffonts merged.pdf
> > name type encoding
> emb
> > sub uni object ID
> > ------------------------------------ ----------------- ----------------
> ---
> > --- --- ---------
> > AYOVHV+Facit-Bold Type 1C Custom
> yes
> > yes yes 131 0
> > AYOVHV+ProximaNova-Bold Type 1C Custom
> yes
> > yes yes 132 0
> > AYOVHV+ProximaNova-Light Type 1C Custom
> yes
> > yes yes 133 0
> > AYOVHV+ProximaNova-Semibold Type 1C WinAnsi
> yes
> > yes yes 134 0
> > ProximaNova-Light Type 1C (OT) Custom
> yes
> > no no 9 0
> > AYOVHV+ProximaNova-Light Type 1C WinAnsi
> yes
> > yes no 192 0
> > AYOVHV+ProximaNova-Light Type 1C WinAnsi
> yes
> > yes no 193 0
> > NPQRGV+ProximaNova-Light Type 1C Custom
> yes
> > yes yes 275 0
> > *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
> > yes yes yes 276 0*
> > NPQRGV+ProximaNova-Bold Type 1C Custom
> yes
> > yes yes 277 0
> > MHGLSX+Facit-Bold Type 1C Custom
> yes
> > yes yes 278 0
> > NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> yes
> > yes yes 437 0
> > NPQRGV+ProximaNova-Light Type 1C WinAnsi
> yes
> > yes yes 438 0
> > ProximaNova-Bold Type 1C (OT) Custom
> yes
> > no no 462 0
> > ProximaNova-Light Type 1C (OT) Custom
> yes
> > no no 512 0
> > NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> yes
> > yes yes 500 0
> > NPQRGV+ProximaNova-Light Type 1C WinAnsi
> yes
> > yes yes 501 0
> > NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> yes
> > yes yes 503 0
> > NPQRGV+ProximaNova-Light Type 1C WinAnsi
> yes
> > yes yes 504 0
> > FJORTL+ProximaNova-Light CID Type 0C Identity-H
> yes
> > yes yes 377 0
> > NPQRGV+ProximaNova-Bold Type 1C WinAnsi
> yes
> > yes yes 451 0
> > NPQRGV+ProximaNova-Light Type 1C WinAnsi
> yes
> > yes yes 452 0
> >
> > Why are the field values not showing up and how can I fix that?
> >
> > Thanks for your help!
> >
> > Johannes
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
> For additional commands, e-mail: users-help@pdfbox.apache.org
>
>
Re: Weird issue with fonts in input fields after merging
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi,
> Am 08.10.2015 um 13:30 schrieb Johannes Barre <jo...@billfront.com>:
>
> Hello!
>
> I have a weird issue. So, I have to PDFs. When I fill form fields in one of
> them and save, everything looks fine. However, when I append this filled
> PDF to another one, xpdf doesn't display the values anymore and complains
> about missing fonts:
>
> Syntax Error: Unknown font tag 'ProximaNova-Regular'
> Syntax Error: Unknown font in field's DA string
> Syntax Error: Unknown font tag 'ProximaNova-Regular'
> Syntax Error: Unknown font in field's DA string
>
> I'm using JRuby (9k), but I hope it's understandable for you. I put the
> source & PDFs in this gist:
> https://gist.github.com/iGEL/a8484f0bc44b03fa9de1 (Will delete it later,
> once the issue is solved)
>
> Other specs: pdfbox-app-1.8.10, openjdk 1.8.0_66, Debian Jessy inside of
> Docker
>
> As you can see, I use a special way to set the values. I had problems with
> German umlauts using setValue and it also sometimes fails (Possibly related
> to https://issues.apache.org/jira/browse/PDFBOX-1550, the message is the
> same as in that bug)
>
setting the field value directly using
form.getField(name).getDictionary.setItem(
Java::OrgApachePdfboxCos::COSName::V,
Java::OrgApachePdfboxCos::COSString.new(value)
)
will not update the visual appearance of the filed and as a result the newly set value is not visible
> The COVER_PAGE.pdf and BIW_FORM.pdf are the templates I'm using,
> form_filled.pdf is just the BIW_FORM.pdf with 2 fields filled and merged is
> COVER_PAGE.pdf and form_filled.pdf merged together.
>
> The p in line 15 and 22 print out the DA value of the field and it's the
> same for both files:
>
> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # form_filled.pdf
> "/ProximaNova-Regular 9 Tf 0.019 0.305 0.627 rg" # merged.pdf
the font resource is called /ProximaNova-Regular but that's not in your PDF as the font which is in your PDF is called /MHGLSX+ProximaNova-Regular. In addition the issue with a font subset is that only certain characters are part of that subset. As a result some of the characters you need to display your field value might not be within the subset.
BR
Maruan
>
> This font is according to pdffonts in both files:
>
> $ pdffonts form_filled.pdf
> name type encoding emb
> sub uni object ID
> ------------------------------------ ----------------- ---------------- ---
> --- --- ---------
> NPQRGV+ProximaNova-Light Type 1C Custom yes
> yes yes 124 0
> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
> yes yes yes 125 0*
> NPQRGV+ProximaNova-Bold Type 1C Custom yes
> yes yes 126 0
> MHGLSX+Facit-Bold Type 1C Custom yes
> yes yes 127 0
> NPQRGV+ProximaNova-Bold Type 1C WinAnsi yes
> yes yes 218 0
> NPQRGV+ProximaNova-Light Type 1C WinAnsi yes
> yes yes 219 0
> ProximaNova-Bold Type 1C (OT) Custom yes
> no no 8 0
> ProximaNova-Light Type 1C (OT) Custom yes
> no no 9 0
> NPQRGV+ProximaNova-Bold Type 1C WinAnsi yes
> yes yes 251 0
> NPQRGV+ProximaNova-Light Type 1C WinAnsi yes
> yes yes 252 0
> NPQRGV+ProximaNova-Bold Type 1C WinAnsi yes
> yes yes 254 0
> NPQRGV+ProximaNova-Light Type 1C WinAnsi yes
> yes yes 255 0
> FJORTL+ProximaNova-Light CID Type 0C Identity-H yes
> yes yes 165 0
> NPQRGV+ProximaNova-Bold Type 1C WinAnsi yes
> yes yes 259 0
> NPQRGV+ProximaNova-Light Type 1C WinAnsi yes
> yes yes 260 0
>
> $pdffonts merged.pdf
> name type encoding emb
> sub uni object ID
> ------------------------------------ ----------------- ---------------- ---
> --- --- ---------
> AYOVHV+Facit-Bold Type 1C Custom yes
> yes yes 131 0
> AYOVHV+ProximaNova-Bold Type 1C Custom yes
> yes yes 132 0
> AYOVHV+ProximaNova-Light Type 1C Custom yes
> yes yes 133 0
> AYOVHV+ProximaNova-Semibold Type 1C WinAnsi yes
> yes yes 134 0
> ProximaNova-Light Type 1C (OT) Custom yes
> no no 9 0
> AYOVHV+ProximaNova-Light Type 1C WinAnsi yes
> yes no 192 0
> AYOVHV+ProximaNova-Light Type 1C WinAnsi yes
> yes no 193 0
> NPQRGV+ProximaNova-Light Type 1C Custom yes
> yes yes 275 0
> *MHGLSX+ProximaNova-Regular Type 1C WinAnsi
> yes yes yes 276 0*
> NPQRGV+ProximaNova-Bold Type 1C Custom yes
> yes yes 277 0
> MHGLSX+Facit-Bold Type 1C Custom yes
> yes yes 278 0
> NPQRGV+ProximaNova-Bold Type 1C WinAnsi yes
> yes yes 437 0
> NPQRGV+ProximaNova-Light Type 1C WinAnsi yes
> yes yes 438 0
> ProximaNova-Bold Type 1C (OT) Custom yes
> no no 462 0
> ProximaNova-Light Type 1C (OT) Custom yes
> no no 512 0
> NPQRGV+ProximaNova-Bold Type 1C WinAnsi yes
> yes yes 500 0
> NPQRGV+ProximaNova-Light Type 1C WinAnsi yes
> yes yes 501 0
> NPQRGV+ProximaNova-Bold Type 1C WinAnsi yes
> yes yes 503 0
> NPQRGV+ProximaNova-Light Type 1C WinAnsi yes
> yes yes 504 0
> FJORTL+ProximaNova-Light CID Type 0C Identity-H yes
> yes yes 377 0
> NPQRGV+ProximaNova-Bold Type 1C WinAnsi yes
> yes yes 451 0
> NPQRGV+ProximaNova-Light Type 1C WinAnsi yes
> yes yes 452 0
>
> Why are the field values not showing up and how can I fix that?
>
> Thanks for your help!
>
> Johannes
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org