Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request for the future: PDF layers #269

Closed
Richard-Mlynarik opened this issue Jul 17, 2011 · 32 comments
Closed

Feature request for the future: PDF layers #269

Richard-Mlynarik opened this issue Jul 17, 2011 · 32 comments
Assignees

Comments

@Richard-Mlynarik
Copy link

@Richard-Mlynarik Richard-Mlynarik commented Jul 17, 2011

That is all.

The code looks really promising!

@arturadib
Copy link
Contributor

@arturadib arturadib commented Oct 7, 2011

Not clear what this means. User is no longer active on Github. Can reopen if asked.

@arturadib arturadib closed this Oct 7, 2011
@Richard-Mlynarik
Copy link
Author

@Richard-Mlynarik Richard-Mlynarik commented Oct 7, 2011

Let me Google that for You.

http://www.google.com/search?q=site:adobe.com+pdf+layer
http://www.google.com/search?q=site:adobe.com+pdf+%22optional+content+group%22

Standard since PDF specification 1.5.
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf
section 8.11.3 "Making Graphical Content Optional"

Present in the UI of every Adobe PDF viewer for about a billion years now.
PDF layers usefully correspond to Illustrator (and similar) drawing program layers, to layers in GIS output, etc.

I'd be more "active" on github (and with other free software) if I enjoyed being slapped about more. (I've stopped using Firefox since the "upgrade" that killed off the truly useful http://code.google.com/p/firefox-mac-pdf/ plugin, which also lacked PDF layer support but otherwise worked very nicely indeed. Browser with no PDF viewing = useless. Safari at least manages that, for all its other crapitude.)

@arturadib arturadib reopened this Oct 7, 2011
@arturadib
Copy link
Contributor

@arturadib arturadib commented Oct 7, 2011

Hey there, didn't mean to insult you! We're doing an issue clean-up, so please forgive closing the issue on you.

And thanks for the detailed response - it definitely clarified what you meant.

Second-guessing terse user requests is a tough thing to do -- did the user mean "layers" at the UI/viewer level, or spec level (optional content), etc? I thought about inquiring here, but I wrongly assumed the odds of a response were low given that your only activity on Github was this comment (we're flattered! :)).

As I said, reopening is definitely an option - consider it done.

Thanks again.

@ghost ghost assigned notmasteryet Nov 18, 2011
@blerner
Copy link

@blerner blerner commented Jan 8, 2013

I've uploaded a tiny file here that demonstrates broken rendering behavior for optional content groups and/or clipping paths (I'm not sure which thing is actually causing the bad behavior). If you try adding #textLayer=visible to the url, you can see that pdf.js is correctly finding and rendering the text, but is just not handling the rest of the rendering correctly.

(This particular PDF came about due to my working on this approach to rendering links in LaTeX using highlighting instead of boxes. The text is rendered into the current clipping path (7 Tr) rather than as normal text (0 Tr), then the clipping path is filled with the normal text color and, within an optional content group, filled again using the highlight color. IIRC, canvas.js#L982 already has some support for adding text to the clipping path, but it doesn't seem to be working here... As a result, this comment may not be 100% applicable to t his bug; feel free to redirect me to a more appropriate one if it exists ;-))

@brendandahl
Copy link
Contributor

@brendandahl brendandahl commented Jan 8, 2013

@blerner I think this issue is different than what you're asking about. Can you open a new issue with your comment above?

@gitspeare
Copy link

@gitspeare gitspeare commented Apr 19, 2014

I'm looking for OCG functionality as well... is this on the plans? Can someone point me to the roadmap?

@ghost
Copy link

@ghost ghost commented Dec 4, 2014

Any news on supporting layers? Would be incredible useful. Getting object names would be useful too (as in object and group names you can set in Illustrator)

@Woodgnome
Copy link

@Woodgnome Woodgnome commented Apr 27, 2015

I'm also interested in knowing when layers will be supported (specifically showing/hiding them).

@timvandermeij
Copy link
Contributor

@timvandermeij timvandermeij commented Apr 27, 2015

There is no implementation for this yet and as far as I know no-one is working on this. If someone wants to work on this, feel free to create a pull request.

@THausherr
Copy link
Contributor

@THausherr THausherr commented Jun 16, 2016

Files with OCGs:
http://ims.er.usgs.gov/images/USTopo/
(not all, only the huge ones)

@boundaryfree
Copy link

@boundaryfree boundaryfree commented Mar 1, 2017

Also expect this feature. Get layers info/showing layer/hiding layer.

@boundaryfree
Copy link

@boundaryfree boundaryfree commented Oct 20, 2017

Hi, also expect OCGs (layer) supports. Any schedule?
@timvandermeij The attachment is a pdf file exported from a architectural drawing containing hundreds of layers.
OCGs_demo.PDF

@timvandermeij
Copy link
Contributor

@timvandermeij timvandermeij commented Oct 20, 2017

Currently this feature is not planned to be implemented. If someone wants to work on this, please let us know. If you can attach more example PDF files here, that would help to get people started and verify their work.

@THausherr
Copy link
Contributor

@THausherr THausherr commented Mar 7, 2019

Here's a simple one:
PDFBOX-4103-OCG.pdf

@gitspeare
Copy link

@gitspeare gitspeare commented Mar 7, 2019

an old example with transparency and ocgs, it'd be nice if the ocgs were selectable from within a browser/ page
_myChessboardv1.2_mockup_ImageArray_beta0.7 - public.pdf

@timvandermeij
Copy link
Contributor

@timvandermeij timvandermeij commented Feb 13, 2020

Nobody is currently working on this. If anyone wants to contribute, we're always happy to review pull requests.

@Snuffleupagus
Copy link
Collaborator

@Snuffleupagus Snuffleupagus commented Feb 13, 2020

The reason that this isn't implemented yet is most likely because it happens to be a fairly complicated subject, given the way that all of this is described in the PDF specification.
Ignoring a lot of the other specifics surrounding OCGs, section "8.11.3.1 General" of the specification states (note the second point):

When a piece of optional content in a PDF file is determined that it shall be hidden, the following occurs:

  • The content shall not be drawn.
  • Graphics state operations, such as setting the colour, transformation matrix, and clipping, shall still be applied. In addition, graphics state side effects that arise from drawing operators shall be applied; in particular, the current text position shall be updated even for text wrapped in optional content. In other words, graphics state parameters that persist past the end of a marked-content section shall be the same whether the optional content is visible or not.
@ma-rf
Copy link

@ma-rf ma-rf commented Feb 24, 2020

Hey there, I've been trying to find a solution for this issue during the last week and was hoping someone can point me in the right direction.
For my use-case, it would not be necessary to toggle additional layers, I would simply need to hide them in my viewer.

So far I was able to identify the "hidden" layers inside document.js like this:

const hiddenLayers = this.xref.root._map.OCProperties._map.D.get("OFF");

But I could not draw the connection between the layers and the actual content that is rendered by pdf.js. So if anyone could give me a hint how to figure out which data is supposed to be hidden, I'd rellay love to put it to use.

@brendandahl brendandahl self-assigned this Jun 23, 2020
brendandahl added a commit to brendandahl/pdf.js that referenced this issue Jul 14, 2020
Add a new method to the API to get the optional content configuration. Add
a new render task param that accepts the above configuration.
For now, the optional content is not controllable by the user in
the viewer, but renders with the default configuration in the PDF.

All of the test files added exhibit different uses of optional content.

Fixes mozilla#269.
brendandahl added a commit to brendandahl/pdf.js that referenced this issue Jul 14, 2020
Add a new method to the API to get the optional content configuration. Add
a new render task param that accepts the above configuration.
For now, the optional content is not controllable by the user in
the viewer, but renders with the default configuration in the PDF.

All of the test files added exhibit different uses of optional content.

Fixes mozilla#269.
brendandahl added a commit to brendandahl/pdf.js that referenced this issue Jul 14, 2020
Add a new method to the API to get the optional content configuration. Add
a new render task param that accepts the above configuration.
For now, the optional content is not controllable by the user in
the viewer, but renders with the default configuration in the PDF.

All of the test files added exhibit different uses of optional content.

Fixes mozilla#269.
brendandahl added a commit to brendandahl/pdf.js that referenced this issue Jul 15, 2020
Add a new method to the API to get the optional content configuration. Add
a new render task param that accepts the above configuration.
For now, the optional content is not controllable by the user in
the viewer, but renders with the default configuration in the PDF.

All of the test files added exhibit different uses of optional content.

Fixes mozilla#269.
brendandahl added a commit to brendandahl/pdf.js that referenced this issue Jul 16, 2020
Add a new method to the API to get the optional content configuration. Add
a new render task param that accepts the above configuration.
For now, the optional content is not controllable by the user in
the viewer, but renders with the default configuration in the PDF.

All of the test files added exhibit different uses of optional content.

Fixes mozilla#269.
brendandahl added a commit to brendandahl/pdf.js that referenced this issue Jul 17, 2020
Add a new method to the API to get the optional content configuration. Add
a new render task param that accepts the above configuration.
For now, the optional content is not controllable by the user in
the viewer, but renders with the default configuration in the PDF.

All of the test files added exhibit different uses of optional content.

Fixes mozilla#269.

Fix test to work with optional content.

- Change the stopAtErrors test to ensure the operator list has something,
  instead of asserting the exact number of operators.
Snuffleupagus added a commit to Snuffleupagus/pdf.js that referenced this issue Jul 28, 2020
Add a new method to the API to get the optional content configuration. Add
a new render task param that accepts the above configuration.
For now, the optional content is not controllable by the user in
the viewer, but renders with the default configuration in the PDF.

All of the test files added exhibit different uses of optional content.

Fixes mozilla#269.

Fix test to work with optional content.

- Change the stopAtErrors test to ensure the operator list has something,
  instead of asserting the exact number of operators.
Snuffleupagus added a commit to Snuffleupagus/pdf.js that referenced this issue Jul 28, 2020
Add a new method to the API to get the optional content configuration. Add
a new render task param that accepts the above configuration.
For now, the optional content is not controllable by the user in
the viewer, but renders with the default configuration in the PDF.

All of the test files added exhibit different uses of optional content.

Fixes mozilla#269.

Fix test to work with optional content.

- Change the stopAtErrors test to ensure the operator list has something,
  instead of asserting the exact number of operators.
Snuffleupagus added a commit to Snuffleupagus/pdf.js that referenced this issue Aug 1, 2020
Add a new method to the API to get the optional content configuration. Add
a new render task param that accepts the above configuration.
For now, the optional content is not controllable by the user in
the viewer, but renders with the default configuration in the PDF.

All of the test files added exhibit different uses of optional content.

Fixes mozilla#269.

Fix test to work with optional content.

- Change the stopAtErrors test to ensure the operator list has something,
  instead of asserting the exact number of operators.
Snuffleupagus added a commit to Snuffleupagus/pdf.js that referenced this issue Aug 1, 2020
Add a new method to the API to get the optional content configuration. Add
a new render task param that accepts the above configuration.
For now, the optional content is not controllable by the user in
the viewer, but renders with the default configuration in the PDF.

All of the test files added exhibit different uses of optional content.

Fixes mozilla#269.

Fix test to work with optional content.

- Change the stopAtErrors test to ensure the operator list has something,
  instead of asserting the exact number of operators.
Snuffleupagus added a commit to Snuffleupagus/pdf.js that referenced this issue Aug 2, 2020
Add a new method to the API to get the optional content configuration. Add
a new render task param that accepts the above configuration.
For now, the optional content is not controllable by the user in
the viewer, but renders with the default configuration in the PDF.

All of the test files added exhibit different uses of optional content.

Fixes mozilla#269.

Fix test to work with optional content.

- Change the stopAtErrors test to ensure the operator list has something,
  instead of asserting the exact number of operators.
Snuffleupagus added a commit to Snuffleupagus/pdf.js that referenced this issue Aug 3, 2020
Add a new method to the API to get the optional content configuration. Add
a new render task param that accepts the above configuration.
For now, the optional content is not controllable by the user in
the viewer, but renders with the default configuration in the PDF.

All of the test files added exhibit different uses of optional content.

Fixes mozilla#269.

Fix test to work with optional content.

- Change the stopAtErrors test to ensure the operator list has something,
  instead of asserting the exact number of operators.
brendandahl added a commit to brendandahl/pdf.js that referenced this issue Aug 3, 2020
Add a new method to the API to get the optional content configuration. Add
a new render task param that accepts the above configuration.
For now, the optional content is not controllable by the user in
the viewer, but renders with the default configuration in the PDF.

All of the test files added exhibit different uses of optional content.

Fixes mozilla#269.

Fix test to work with optional content.

- Change the stopAtErrors test to ensure the operator list has something,
  instead of asserting the exact number of operators.
brendandahl added a commit to brendandahl/pdf.js that referenced this issue Aug 3, 2020
Add a new method to the API to get the optional content configuration. Add
a new render task param that accepts the above configuration.
For now, the optional content is not controllable by the user in
the viewer, but renders with the default configuration in the PDF.

All of the test files added exhibit different uses of optional content.

Fixes mozilla#269.

Fix test to work with optional content.

- Change the stopAtErrors test to ensure the operator list has something,
  instead of asserting the exact number of operators.
brendandahl added a commit to brendandahl/pdf.js that referenced this issue Aug 3, 2020
Add a new method to the API to get the optional content configuration. Add
a new render task param that accepts the above configuration.
For now, the optional content is not controllable by the user in
the viewer, but renders with the default configuration in the PDF.

All of the test files added exhibit different uses of optional content.

Fixes mozilla#269.

Fix test to work with optional content.

- Change the stopAtErrors test to ensure the operator list has something,
  instead of asserting the exact number of operators.
brendandahl added a commit to brendandahl/pdf.js that referenced this issue Aug 4, 2020
Add a new method to the API to get the optional content configuration. Add
a new render task param that accepts the above configuration.
For now, the optional content is not controllable by the user in
the viewer, but renders with the default configuration in the PDF.

All of the test files added exhibit different uses of optional content.

Fixes mozilla#269.

Fix test to work with optional content.

- Change the stopAtErrors test to ensure the operator list has something,
  instead of asserting the exact number of operators.
@nuthinking
Copy link

@nuthinking nuthinking commented Aug 5, 2020

@brendandahl how does the new API works? What is "Optional Content"? Can't we simply scan existing layers and hide them? Thanks!

@Snuffleupagus
Copy link
Collaborator

@Snuffleupagus Snuffleupagus commented Aug 5, 2020

What is "Optional Content"?

See https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G7.3858031

Can't we simply scan existing layers and hide them?

Unfortunately it's really quite difficult to understand what you're asking here.
Note: This functionality has not yet been integrated into the default viewer, however that'll be addressed in #12170.

@nuthinking
Copy link

@nuthinking nuthinking commented Aug 5, 2020

Sorry, I meant detecting them and having the option to manipulate them (hide, remove, etc...)

@THausherr
Copy link
Contributor

@THausherr THausherr commented Aug 5, 2020

I tried the feature and it works as expected, which is that instead of displaying all layers, it only displays the ones for viewing.

@brendandahl
Copy link
Contributor

@brendandahl brendandahl commented Aug 5, 2020

@brendandahl how does the new API works? What is "Optional Content"? Can't we simply scan existing layers and hide them? Thanks!

The full API still needs a bit more work, but you can pdfDoc.getOptionalContentConfig then iterate over the various optionalContentConfig.groups and set which ones you want to hide/show (optionalContentGroup.visible). Then pass that config into your call to render a page.

Useful links:

getOptionalContentConfig() {

class OptionalContentConfig {

* @property {Promise<OptionalContentConfig>} [optionalContentConfigPromise] -

@nuthinking
Copy link

@nuthinking nuthinking commented Aug 6, 2020

@brendandahl oh, this looks very interesting! I will give it a go. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.