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 < [email protected]> 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 <[email protected]> > wrote: > >> Hi Kevin, >> > Am 14.10.2015 um 12:05 schrieb Johannes Barre < >> [email protected]>: >> > >> > 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 < >> [email protected]> >> > wrote: >> > >> >> Hi Johannes, >> >> >> >> >> >>> Am 14.10.2015 um 11:51 schrieb Johannes Barre < >> >> [email protected]>: >> >>> >> >>> 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 < >> [email protected]> >> >>> wrote: >> >>> >> >>>> Hi, >> >>>> >> >>>>> Am 09.10.2015 um 18:28 schrieb Johannes Barre < >> >>>> [email protected]>: >> >>>>> >> >>>>> 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 < >> [email protected] >> >>> >> >>>>> wrote: >> >>>>> >> >>>>>> Hi, >> >>>>>> >> >>>>>>> Am 08.10.2015 um 16:31 schrieb Johannes Barre < >> >>>>>> [email protected]>: >> >>>>>>> >> >>>>>>> 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 < >> >>>>>> [email protected] >> >>>>>>>> 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 < >> >>>> [email protected]> >> >>>>>>>> wrote: >> >>>>>>>> >> >>>>>>>>> Hi, >> >>>>>>>>> >> >>>>>>>>>>> Am 08.10.2015 um 14:53 schrieb Johannes Barre < >> >>>>>>>>>> [email protected]>: >> >>>>>>>>>> >> >>>>>>>>>> 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 < >> >>>>>> [email protected]> >> >>>>>>>>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>>> Hi, >> >>>>>>>>>>> >> >>>>>>>>>>>>> Am 08.10.2015 um 13:30 schrieb Johannes Barre < >> >>>>>>>>>>>> [email protected]>: >> >>>>>>>>>>>> >> >>>>>>>>>>>> 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: [email protected] >> >>>>>>>>>>> For additional commands, e-mail: [email protected] >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >> --------------------------------------------------------------------- >> >>>>>>>>> To unsubscribe, e-mail: [email protected] >> >>>>>>>>> For additional commands, e-mail: [email protected] >> >>>>>>>> >> >>>>>> >> >>>>>> >> --------------------------------------------------------------------- >> >>>>>> To unsubscribe, e-mail: [email protected] >> >>>>>> For additional commands, e-mail: [email protected] >> >>>>>> >> >>>>>> >> >>>> >> >>>> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >
