Tilman, I don't mind doing a little work for you to integrate it into the trunk but I have some reservations; largely, I am not sure that I implemented it properly with regards to the PDF spec. I know it works for the GeoPDFs I have been working on (and unrelated to the layers I have a pile of code that sifts out the GeoPDF encoding and does the translations), but of course that doesn't mean I did it right. For example, I find it odd that I didn't have to implement BMC.
I think that you do have to be concerned about the hierarchy. At least from an end-user perspective in Acrobat if you hide a parent layer all the children layers become hidden. So I think hiding the parent layer in the library should cause the same result. Often in a PDF the parent layer is only there for grouping purposes and itself has no content. What I couldn't say for certain is if you ever get a PDF that is encoded outside of my expectations. For example, given sibling layers A and B, will you ever get a PDF where content for B appears inside content for A. In the reference PDFs I have the answer is no but it seems that is possible in physics - being unfamiliar with the actual PDF spec I don't know if this is a contractual thing or what. I wrote the code to be that you mark the hidden entries mostly because that was my mentality. It offers a slight economy because the code that determines if the current stack is hidden searches a smaller list (the current stack vs. the list of all the layers). If you flipped it around you would only know if you were hiding if every entry in the current stack was present in the keep list. What I really wanted was to key off the true/false status in the optional content groups (the API) but I didn't have the understanding of the library to figure out how to get into that at the right time. I also would have really liked to have the index name (MC1,etc) be present in the OCG class. Funny enough that is what cost me the most amount of time, figuring out how to get a map between them. It's all their of course, it just was not obvious to me. To be honest though all this is a trivial change to the library. Other than BDP & EMP which are nearly empty classes, the only real thing that matters was processStreamOperators() which is only a handful of lines different. I would think you could go in and make these changes in a few minutes and probably be quite satisfied with the results. Most of the code in my example is really just dealing with the fact I extended your classes rather than fork the project. To do a full implementation though I would suggest extending the OCG pojos to include the index name and use the true/false value there to drive the code. That's what I did when I first got the library - I set some OCG layers to false in the POJO and then became surprised when they still rendered. So I think that's the natural way to use the library vs. building some other list of things you want to keep or get rid of. -cal On Thu, Jun 16, 2016 at 9:09 AM, Tilman Hausherr <[email protected]> wrote: > I'd be interested in this, but not as an extension, rather as a change in > the trunk. Our two main java competitors both can do it. > > I'd prefer that the PDFRenderer and PageDrawer remain as they are, but > that the PDFRenderer gets a new setter for the map, e.g. setOCG() or > setOCGMap(). This map would then be passed in PageDrawerParameters. Btw > shouldn't we put into the map what we want to keep? Is there a good > argument to do it one way or the other? Do we have to care about the > hierarchy? > > The IDs are in the PDF... open a file with the PDFDebugger-App and you'll > see :-) > > There is a file with OCGs at PDFBox > reactor\pdfbox\target\test-output\ocg-generation.pdf > > Other files with layers: > - gs-bugzilla689931.pdf > - gs-bugzilla693548-STACKOVERFLOW.pdf > - gs-bugzilla692933.pdf > - many maps at http://ims.er.usgs.gov/images/USTopo/ (the huge files) > > So if you're willing to change your code accordingly, please open an issue > in JIRA, and attach your code as a patch / diff. > > https://issues.apache.org/jira/browse/PDFBOX > > Tilman > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- C. Alexander Leigh
