pdfbox-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maruan Sahyoun <sahy...@fileaffairs.de>
Subject Re: Weird issue with fonts in input fields after merging
Date Fri, 30 Oct 2015 22:20:52 GMT
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
>>> 
>>> 
>> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message