On 17.03.2008 19:43:30 thebluemountain wrote:
> Jeremias,
>
> 1- i actually have several other metadatas to associate to the attachment:
> a- the name of the user that associated the file
> b- the date it was done
> c- a status regarding the attached file, ...
Sounds like a job for an XMP metadata stream to be attached to the
embedded file for the values that are not listed in table 3.34 in PDF
1.4 (page 125). That's PDF's recommended way to associate metadata with
an object, although private dictionary entries would probably work, too.
The thing is that you could reuse FOP's metadata functionality for the
embedded file extension.
> while i could use embeddedfiles dictionary at pdf level and i could try to
> pack
> all informations in the description PDF entry but i was rather interested in
> the
> use of FOP to embed not only file, but also these related informations in the
> pdf. therefore, it looked like a PDFLink (that goes through annotation as
> well),
> except it does not refers to any text element within.
>
> i am intending to get someting in the pdf like:
>
> + {date} {user} {status} [file]: {comment}
> + {date2} {user2} {status2} [file2]: {comment2}
Ah, so you don't want just a non-visual file attachment but actually a
file attachment annotation with a visual representation on a page? Do I
understand you correctly that the above is some text output on the PDF
page and there will be a rectangle around it that points to the embedded
file?
> 2- i've been contacting Andrejus a few days ago but the implementation i saw
> uses xobject rather than embeddedfile (EF) object.
If you've read my comments to his patch, you've seen that the XObject
was a mistake. The other things were basically design issues. His
approach otherwise was fine.
> therefore, i am in the
> process of writing an extension ... that would behave like a fo:basic-link
> except it does not accept any other object inside.
Why? Maybe someone else would want the annotation to lie on some text or
another object. It's important not to restrict the usage of such a
feature too much.
> therefore, i was thinking of an empty area (to reserve space) and an
> annotation.
>
> do you think i could go the other way (regular embeddedfiles) with the other
> requirements (associated meta-datas) ?
I think we should try to cover both your and Andrejus' requirements.
Andrejus simply wants an embedded file (File Specification), if I
understood him correctly. You obviously want a clickable annotation.
Both approaches rely on a "File Specification" (PDF 1.4, ch 3.10). Why
not create a non-visual extension for that? Something like:
[..]
<fo:declarations>
<fox:embedded-file id="myfile1" src="files/embedded-file.bin">
<x:xmpmeta xmlns:x="adobe:ns:meta/">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";>
<rdf:Description about="" xmlns:dc="http://purl.org/dc/elements/1.1/";>
<dc:creator>Daniel</dc:creator>
<dc:date>2003-04-15T16:05:06Z</dc:date>
</rdf:Description>
<rdf:Description about="" xmlns:my="http://my.company.com/metadata";>
<my:status>draft</my:status>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
</fox:embedded-file>
</fo:declarations>
Using XMP you have an unrestricted way to define any metadata you want,
including private namespaces (like I did in my example for your status
info). The dc:date could be extracted (if available) and put in the
predefined dictionary entries for the "Params" dictionary on the file
stream.
That's the first part. Then comes your additional requirement: We could
define an extension element for the "File Attachment Annotation", for
example:
<fox:file-attachment-annotation embedded-file-reference="myfile1">
<fo:[anything]......
</fox:file-attachment-annotation>
That could be implemented as an adjusted copy of BasicLinkLayoutManager,
i.e. for example a FileAttachmentAnnotationLayoutManager. That would
allow maximum reuse of existing code for link annotations already
present as the mechanism is quite similar.
At any rate, if we want to add to FOP something that is useful for more
than just one user, we have to produce the following:
- A specification for the extensions (can be drafted up in the Wiki):
- Representation in XSL-FO.
- The PDF objects to be generated.
- The behaviour for non-PDF renderers (they should still work if the
extension appears even if the renderers don't support that feature).
- A patch with the necessary changes.
- Documentation so other people can use this feature, too.
Given that there will be new files in the patch, CLAs [1] will be
required by each contributor.
[1] http://www.apache.org/licenses/#clas
BTW, we should move this discussion to the fop-dev mailing list.
WDYT?
> Daniel,
>
> > On 17.03.2008 09:43:37 thebluemountain wrote:
> > > Hi,
> > >
> > > I need to support embedding files as attachment when generating pdf file.
> > >
> > > I've been
> > > - registering my element (using element mapping class). the Attachment
> > class
> > > extends the AbstractGraphics
> >
> > An embedded file doesn't have any visual appearance in the PDF file so
> > deriving from AbstractGraphics is wrong.
> >
> > > now, for the layout manager, i've been trying to extend the
> > > AbstractGraphicsLayoutManager: however, the class defines a method
> > > abstract
> > Area
> > > getChildArea() that prevents from extending, unless from same package.
> > >
> > > What i've then been doing was copying the AbstractGraphicsLayoutManager
> > code
> > > into my AttachmentLayoutManager that now extends LeafNodeLayoutManager.
> > >
> > > 1- Is there any reason the getChildArea () is restricted to classes in
> > > same
> > > package ?
> >
> > AFAIK, noone has written an external extension that requires a layout
> > manager, yet. It could very well be that this will require some tweaking
> > the first time someone does that. But as mentioned above for your case
> > this is the wrong approach.
> >
> > > 2- Should I do it another way ?
> >
> > Yes. Take a look at https://issues.apache.org/bugzilla/show_bug.cgi?id=44460
> > Andrejus Chaliapinas has already started to write a patch for the same
> > thing. I rejected the first patch because of the issues listed. Andrejus
> > hasn't submitted a new version since. Maybe you can help him finish the
> > patch the way we need it. You can contact him through the Bugzilla issue.
> > I'll gladly review the improved patch once it's available.
> >
> > > Thank you for your help
> > >
> > > Daniel
> >
> >
> >
> > Jeremias Maerki
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> le
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
