There’s a link in the article from the words “in this instructional video”…

Yes, it’s possible.

Please see comment #15 in my Correspondence Management post for more information.

In workbench, can a fragment be referenced with an absolute path?

thank you

You should be able to create fragments that contain multiple pages — multiple “page subforms”, that is, which means that each subform is the size of a page. Start with a form that has two pages and add the “general information” content to them appropriately. The select both page subforms and create a fragment from them. When you reference that fragment from another form, drag it into the form and then use the Hierarchy palette to move the fragment into the root subform (i.e. as a child of the root subform). In this way, the fragment containing two “page subforms” will act as two pages in your form.

Thanks a lot for your tutorial. I had a look in it and it helped.
But I got a bigger problem.

Description:
We have got about 50 forms that all have the same structure:

- PAGE 1 & 2: General Infomation (page 1/3, page 2/3) –> for all 50 forms the same
- PAGE 3: Specific Information (page numbering 3/3) –> for each form different
- PAGE 4 & 5: Riskinformation (page 1/2, page 2/2) –> for all 50 forms the same

All these form parts should be put together and saved as one pdf. Finally 50 pdf who just differ in page3. I need 50 flat and static pdf because the will be saved seperately.
I tried to define fragments over multiple pages to keep the “General Information” pages together but that did’nt work out.

Do you have any idea to solve that problem in a other way.

Thank you very much for your input.

Kind regards Joerg

Fragments are tools meant for design-time use. Once the form is saved as a PDF and used in Acrobat, it is self-contained. The intention of the Fragments feature is to make it easy to re-use common pieces of your forms and scripts.

I would love to have a look at your forms but I couldn’t promise any kind of decent turn-around time at the moment. Things are crazy at Adobe in preparation for the MAX conference, we have a new development cycle in full swing and I’ve got many other commenters waiting for responses. If there are areas which you’re uncertain of, perhaps you could just ping me on those?

The time that takes to transform a xdp to a pdf is, in fact, just one reason for us to want to work with PDF from the begining. The second reason is that we work with many offices with a low bandwith. As so, we must distribute the files to the offices at first hand. To install LC Forms in all the offices is expensive, but worst, it needs java and more time to maintain.

So, as far as I understood, fragments would be usefull for us at design time. Right?

Stefan, just one more thing: is it possible to upload 2 examples of PDF with functionality that we need? I would like to have your opinion on them. Most of this functionality is actually a mix of many post you have made in your form. These are working examples, thus I´m not asking for you to work on them, but just to give your opinion about if we choose the best way to implement it.

Thank you

You’re on the right track so let’s see if I can clear things up for you.

First of all, fragments are pieces of XFA mark-up located in an XDP that can be referenced from other forms (in other files). Those other forms can either be XDP or PDF files. If the fragment is located in a PDF form, you will not be able to reference it from other forms (XDP or PDF).

When the browser makes a call for an XDP form served by LC Forms, the server will resolve all fragment references in the XDP (if any), generate a self-contained (portable) PDF form and serve the PDF back to the browser.

Whether or not the process of transforming an XDP into a PDF becomes a time-consuming operation (to the point that it creates a noticeable delay) will depend on the complexity of the XDP form itself. All I can say, personally, is that LC Forms is a very mature server product which has undergone many stress-testing exercises to ensure that it meets strict performance parameters.

If you’re really concerned with the amount of time it may take for LC Forms to convert an XDP into a PDF, you could always save your form as a PDF file to begin with, using Designer. When you save a form as PDF in Designer, all fragment references will be resolved and stored into that PDF similarly to how they would be when LC Forms renders an XDP into a PDF. The PDF form you end-up with in Designer is also a self-contained PDF form which you can distribute. Designer simply does some magic under the covers to retain the original fragment references so that you can continue to work with them when you edit the form. Since LC Forms can serve PDF files just like it can serve XDPs, you may be able to cut down on the time required to serve the form to the browser since a conversion into PDF wouldn’t have to take place as part of the transaction. But I’m not an LC Forms “expert” so I can’t guarantee this would be the case. Someone on the LC Forms Forum may have a more definite answer.

Nice video, however I have a question about fragments: How they work at runtime on the client browser?

As far as I understood, a fragment its a kind of reference to another template, that is why changing the fragment will change the templates that have a reference to it. But what happen when one gets a form in the browser? And can we use fragments in PDF or just in XDP?

I believe this would work like this: the browser makes a call for a template; Form server will render the XDP to PDF, while rendering it will get all the fragments and thus the resulting PDf will have all the fragments on it (and without any more references).

But if this true, it means that to use fragments one can´t work with PDF templates from the beggining. Working with XDP means that, for each call to the template (referencing fragments), a transformation to PDf must be made, and this is time consuming.

Am I right, or I´m missing something?

Thank you