Byte Offsets in the XREF table #16
Replies: 5 comments 9 replies
-
|
I'd consider one of the two options:
Btw, how does this work together with the PDF editing capabilities of RUPS? I.e. when something is changed in the document, what would/should happen with these offsets? Should we update them? Should we hide this info? Should we only show this info in read-only mode? |
Beta Was this translation helpful? Give feedback.
-
This sounds pretty reasonable. Granted, RUPS currently doesn't offer introspection of object streams, so that offset isn't immediately actionable, but it's indeed more useful than just printing the offset of the stream itself, IMHO. I think the most tricky aspect is making it obvious in the UI what the second number refers to. There are at least three ways to read that number (without the context of this conversation):
All of these are positive integers so they look the same. Perhaps a tooltip or a prefix would help :) |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, the offset within the stream might be more useful, but not immediately I would say. At least not until RUPS offers an insight into that stream. That being said, I'm thinking long the lines of:
Which may prove to be too long, so perhaps:
Or do our own shorthand:
As for the updating question. As of now, the changes you make before saving are not reflected in the XREF table, simply because the objects haven't been written yet and as such have no XREF entry. Saving does reload the document and as such, the XREF table as well. |
Beta Was this translation helpful? Give feedback.
-
|
Indeed it's the index within the object stream. Thus, probably |
Beta Was this translation helpful? Give feedback.
-
|
Would you prefer index or offset within the stream? |
Beta Was this translation helpful? Give feedback.
-
|
I guess index would be more useful, especially since it's indeed how objects are referred in the PDF syntax itself. And if it'd be possible to introspect the contents of the object stream, indexes will be much more intuitively useful rather than offsets. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I also like the |
Beta Was this translation helpful? Give feedback.
-
|
I'm looking into writing Not completely sold on the placement of this, but this allows me to reuse the main view. |
Beta Was this translation helpful? Give feedback.
-
|
If I could have a wish list (and I appreciate that development complexity is a separate issue) then it would include:
I think this also means that the RUPS view of the trailer needs to show that it is really an XRefStream and not a traditional (simplified) trailer. Maybe this is as simple as showing the Separately:
|
Beta Was this translation helpful? Give feedback.
-
|
Hi Peter,
As for RUPS not showing the custom keys in the trailer: I already looked into the issue and this is actually a bug in iText's behaviour. iText RUPS uses PdfDocument, but in stamping mode, to manipulate PDF files. This mode unfortunately took a shortcut by reusing the "new document" mode for the /Trailer dict and re-instantiates the object. This meant that it's ignoring custom entries. I've added a fix and I'm going through the merging process. RUPS did no extra analysis/validation/cleaning in this case, so it should be fixed moving forward. And yeah, RUPS is complaining about that as well for ObjStm but it does read them perfectly, make sure to double check the Stream tab, while we work to get rid of that message. |
Beta Was this translation helpful? Give feedback.
-
If memory serves, RUPS will try parsing any stream as a content stream by default, and log errors if that fails, which isn't particularly elegant. You'll see similar behaviour on metadata streams. There's separate handling for image data, though, so perhaps it's not too difficult to add "nice" handling for other commonly used stream types. Examples I can think of right now: XMP metadata, object streams, xref streams, embedded file streams. All of these should be identifiable as such without requiring any extra context if the stream extent dictionary contains all required keys, so it sounds feasible... It's been a while since I looked at that area of the source, though :). |
Beta Was this translation helpful? Give feedback.
-
|
Thanks Michaël and Matthias! Separate question: RUPS displays JPEG (DCTDecode) images fine and logs console messages for not being able to do the same for JPEG 2000. That's all good. However, for JBIG2 images, I get "Image can't be loaded" white text on a red background in the Stream tab, but no console message. Does this mean the JBIG2 image data in question is potentially corrupt or is the support missing as per JPEG 2000 but just not logged? |
Beta Was this translation helpful? Give feedback.
-
|
RUPS delegates the rendering to the Java APIs, it might just be that Java doesn't support it properly. |
Beta Was this translation helpful? Give feedback.
-
|
FYI: #29 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi all,
A few weeks back, I implemented a rudimentary byte offset in the XREF table and I wanted to collect some feedback on this. Especially on how Object streams are handled.
In the current implementation, if an object resides in an object stream then the byte offset is the offset to the object stream that contains the object. I feel that this is the preferred way of dealing with these, but I wanted to hear other opinions on whether or not it should show it.
Beta Was this translation helpful? Give feedback.
All reactions