PDF full screen mode...

[Jiri Tyr]

Hello,

I would like to ask you if FOP can create a PDF file with a flag which
would put Acrobat Reader to full screen mode. When I create a
presentation in LaTeX PowerDot or Beamer, it creates PDF which ask the
user of Acrobat Reader if he/she wants to allow the document to enter
full screen mode.

Best Regards,
Jiri

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Andreas Delmelle-2]

On Jun 10, 2008, at 11:18, Jiri Tyr wrote:

> I would like to ask you if FOP can create a PDF file with a flag  
> which would put Acrobat Reader to full screen mode. When I create a  
> presentation in LaTeX PowerDot or Beamer, it creates PDF which ask  
> the user of Acrobat Reader if he/she wants to allow the document to  
> enter full screen mode.

The short answer: To my knowledge, FOP currently offers no such  
possibility...

The longer answer:
... yet. IIC, it shouldn't be too difficult to tie in support for  
something like this, but I'd need a closer look at the PDF spec to  
say for sure. For PDF /GoTo and /GoToR actions, I know it is possible  
to specify some settings/hints for the viewer application. In theory,  
such hints could be passed to the renderer via extension properties/
attributes on the fo:basic-link element. I guess something similar is  
possible for specifying settings to use when opening the PDF itself.

If anyone feels like diving into it, patches are always welcome. For  
pointers into the related code, just drop us a line on fop-dev@


Cheers

Andreas

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Andreas Delmelle-2]

On Jun 10, 2008, at 13:16, Andreas Delmelle wrote:

> On Jun 10, 2008, at 11:18, Jiri Tyr wrote:
>
>> I would like to ask you if FOP can create a PDF file with a flag  
>> which would put Acrobat Reader to full screen mode. When I create  
>> a presentation in LaTeX PowerDot or Beamer, it creates PDF which  
>> ask the user of Acrobat Reader if he/she wants to allow the  
>> document to enter full screen mode.
>
> The short answer: To my knowledge, FOP currently offers no such  
> possibility...
>
> The longer answer:
> ... yet. IIC, it shouldn't be too difficult to tie in support for  
> something like this, but I'd need a closer look at the PDF spec to  
> say for sure.

Just took a very quick look, and the relevant part of the PDF  
Reference (v1.5) is "3.6.1 Document Catalog". In the catalog, an  
entry /PageMode can be set to "FullScreen" to obtain the effect that  
you seem to be looking for.

Remains the question of how to add this hint in the FO-file, and  
output the /PageMode tag in the catalog when needed.



Cheers

Andreas

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Philipp Wagner]

Andreas Delmelle schrieb:
> Remains the question of how to add this hint in the FO-file, and output
> the /PageMode tag in the catalog when needed.

I just had a look how other formatters are doing that.

Antenna House uses a document-info tag below the <fo:root> element, see
the specs here: http://www.antennahouse.com/xslfo/axf3-extension.htm

RenderX XEP does it using a processing instruction like
<?xep-pdf-view-mode full-screen?>
specs: http://www.renderx.com/reference.html#Initial_Zoom

I actually like the Antenna House variant a bit better, but
document-info seems still to be the wrong name for it ;)

Philipp

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Andreas Delmelle-2]

On Jun 11, 2008, at 17:42, Philipp Wagner wrote:

> Andreas Delmelle schrieb:
>> Remains the question of how to add this hint in the FO-file, and  
>> output the /PageMode tag in the catalog when needed.
>
> I just had a look how other formatters are doing that.
>
> Antenna House uses a document-info tag below the <fo:root> element,  
> see the specs here: http://www.antennahouse.com/xslfo/axf3- 
> extension.htm
>
> RenderX XEP does it using a processing instruction like
> <?xep-pdf-view-mode full-screen?>
> specs: http://www.renderx.com/reference.html#Initial_Zoom
>
> I actually like the Antenna House variant a bit better, but  
> document-info seems still to be the wrong name for it ;)

Personally, I was thinking in that direction, but something like  
fox:pdf-catalog, which would not only allow users to specify the /
PageMode, but basically anything that can be provided there (also the  
more general /ViewerPreferences for example...) Obviously, that  
extension element would be completely ignored for other output formats.

Anyway: Thanks for looking this up and sharing the info!

Cheers

Andreas

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Jiri Tyr]

Any progress in this topic? What is necessary to do to have this feature
in FOP?

Best Regards,
Jiri


Andreas Delmelle wrote:

> On Jun 11, 2008, at 17:42, Philipp Wagner wrote:
>
>> Andreas Delmelle schrieb:
>>> Remains the question of how to add this hint in the FO-file, and
>>> output the /PageMode tag in the catalog when needed.
>>
>> I just had a look how other formatters are doing that.
>>
>> Antenna House uses a document-info tag below the <fo:root> element,
>> see the specs here: http://www.antennahouse.com/xslfo/axf3-extension.htm
>>
>> RenderX XEP does it using a processing instruction like
>> <?xep-pdf-view-mode full-screen?>
>> specs: http://www.renderx.com/reference.html#Initial_Zoom
>>
>> I actually like the Antenna House variant a bit better, but
>> document-info seems still to be the wrong name for it ;)
>
> Personally, I was thinking in that direction, but something like
> fox:pdf-catalog, which would not only allow users to specify the
> /PageMode, but basically anything that can be provided there (also the
> more general /ViewerPreferences for example...) Obviously, that
> extension element would be completely ignored for other output formats.
>
> Anyway: Thanks for looking this up and sharing the info!
>
> Cheers
>
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@...
> For additional commands, e-mail: fop-users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Justus-bulk]

Are processor-specific fo extensions really the generally-accepted way
to go? I'd hesitate because this requires processor-specific XSLT
customizations. Are there really no better ways to to pass
document-specific parameters to the FO processor: command-line
options, .properties files, ...

Justus

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Jeremias Maerki-2]

I'm not aware of any patches submitted for this.

On 11.07.2008 11:31:18 Jiri Tyr wrote:

> Any progress in this topic? What is necessary to do to have this feature
> in FOP?
>
> Best Regards,
> Jiri
>
>
> Andreas Delmelle wrote:
> > On Jun 11, 2008, at 17:42, Philipp Wagner wrote:
> >
> >> Andreas Delmelle schrieb:
> >>> Remains the question of how to add this hint in the FO-file, and
> >>> output the /PageMode tag in the catalog when needed.
> >>
> >> I just had a look how other formatters are doing that.
> >>
> >> Antenna House uses a document-info tag below the <fo:root> element,
> >> see the specs here: http://www.antennahouse.com/xslfo/axf3-extension.htm
> >>
> >> RenderX XEP does it using a processing instruction like
> >> <?xep-pdf-view-mode full-screen?>
> >> specs: http://www.renderx.com/reference.html#Initial_Zoom
> >>
> >> I actually like the Antenna House variant a bit better, but
> >> document-info seems still to be the wrong name for it ;)
> >
> > Personally, I was thinking in that direction, but something like
> > fox:pdf-catalog, which would not only allow users to specify the
> > /PageMode, but basically anything that can be provided there (also the
> > more general /ViewerPreferences for example...) Obviously, that
> > extension element would be completely ignored for other output formats.
> >
> > Anyway: Thanks for looking this up and sharing the info!
> >
> > Cheers
> >
> > Andreas

Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Jeremias Maerki-2]

Yes, the FO spec allows that. Please realize that some people want one
feature to be configurable in the config file. Others want to access it
programmatically. And others want to include it in the FO file. Often we
end up doing the same in more than one places.

On 11.07.2008 12:27:09 Justus-bulk wrote:
> Are processor-specific fo extensions really the generally-accepted way
> to go? I'd hesitate because this requires processor-specific XSLT
> customizations. Are there really no better ways to to pass
> document-specific parameters to the FO processor: command-line
> options, .properties files, ...
>
> Justus


Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Jiri Tyr]

So it is necessary to create some special interface for this purpose? I
mean some general interface for input from a config file and from FO
file. If this interface exists it should not be difficult to change any
property from users Java program.

How difficult it can be to implement such think in FOP? If somebody have
a time to sketch out the solution, it would be great.

Jiri


Jeremias Maerki wrote:

> Yes, the FO spec allows that. Please realize that some people want one
> feature to be configurable in the config file. Others want to access it
> programmatically. And others want to include it in the FO file. Often we
> end up doing the same in more than one places.
>
> On 11.07.2008 12:27:09 Justus-bulk wrote:
>> Are processor-specific fo extensions really the generally-accepted way
>> to go? I'd hesitate because this requires processor-specific XSLT
>> customizations. Are there really no better ways to to pass
>> document-specific parameters to the FO processor: command-line
>> options, .properties files, ...
>>
>> Justus
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@...
> For additional commands, e-mail: fop-users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Jeremias Maerki-2]

Take a look at the XMP metadata extension which is quite similar to
what's necessary here:
src/java/org/apache/fop/fo/extensions/xmp/*.java
The PDFRenderer has to be extended, too, to catch the
ExtensionAttachment subclass for the extension and react on it.

It's not too difficult to implement this but it takes a few changes in
at least three packages. It also requires learning a bit about PDF so
you can extend the PDF library accordingly. HTH

On 11.07.2008 14:27:59 Jiri Tyr wrote:

> So it is necessary to create some special interface for this purpose? I
> mean some general interface for input from a config file and from FO
> file. If this interface exists it should not be difficult to change any
> property from users Java program.
>
> How difficult it can be to implement such think in FOP? If somebody have
> a time to sketch out the solution, it would be great.
>
> Jiri
>
>
> Jeremias Maerki wrote:
> > Yes, the FO spec allows that. Please realize that some people want one
> > feature to be configurable in the config file. Others want to access it
> > programmatically. And others want to include it in the FO file. Often we
> > end up doing the same in more than one places.
> >
> > On 11.07.2008 12:27:09 Justus-bulk wrote:
> >> Are processor-specific fo extensions really the generally-accepted way
> >> to go? I'd hesitate because this requires processor-specific XSLT
> >> customizations. Are there really no better ways to to pass
> >> document-specific parameters to the FO processor: command-line
> >> options, .properties files, ...
> >>
> >> Justus
> >
> >
> > Jeremias Maerki
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-users-unsubscribe@...
> > For additional commands, e-mail: fop-users-help@...
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@...
> For additional commands, e-mail: fop-users-help@...

Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Jiri Tyr]

Can you send me some example of FO with the fox:pdf-catalog example?
Then I could try to investigate if I can clone and modify the XMP for
this purpose.

Jiri


Jeremias Maerki wrote:

> Take a look at the XMP metadata extension which is quite similar to
> what's necessary here:
> src/java/org/apache/fop/fo/extensions/xmp/*.java
> The PDFRenderer has to be extended, too, to catch the
> ExtensionAttachment subclass for the extension and react on it.
>
> It's not too difficult to implement this but it takes a few changes in
> at least three packages. It also requires learning a bit about PDF so
> you can extend the PDF library accordingly. HTH
>
> On 11.07.2008 14:27:59 Jiri Tyr wrote:
>> So it is necessary to create some special interface for this purpose? I
>> mean some general interface for input from a config file and from FO
>> file. If this interface exists it should not be difficult to change any
>> property from users Java program.
>>
>> How difficult it can be to implement such think in FOP? If somebody have
>> a time to sketch out the solution, it would be great.
>>
>> Jiri
>>
>>
>> Jeremias Maerki wrote:
>>> Yes, the FO spec allows that. Please realize that some people want one
>>> feature to be configurable in the config file. Others want to access it
>>> programmatically. And others want to include it in the FO file. Often we
>>> end up doing the same in more than one places.
>>>
>>> On 11.07.2008 12:27:09 Justus-bulk wrote:
>>>> Are processor-specific fo extensions really the generally-accepted way
>>>> to go? I'd hesitate because this requires processor-specific XSLT
>>>> customizations. Are there really no better ways to to pass
>>>> document-specific parameters to the FO processor: command-line
>>>> options, .properties files, ...
>>>>
>>>> Justus
>>>
>>> Jeremias Maerki

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Jeremias Maerki-2]

I'll defer to the interested parties to design that. I haven't looked
into what would be necessary to have. But design work should probably be
done over on fop-dev@....

On 11.07.2008 15:22:03 Jiri Tyr wrote:

> Can you send me some example of FO with the fox:pdf-catalog example?
> Then I could try to investigate if I can clone and modify the XMP for
> this purpose.
>
> Jiri
>
>
> Jeremias Maerki wrote:
> > Take a look at the XMP metadata extension which is quite similar to
> > what's necessary here:
> > src/java/org/apache/fop/fo/extensions/xmp/*.java
> > The PDFRenderer has to be extended, too, to catch the
> > ExtensionAttachment subclass for the extension and react on it.
> >
> > It's not too difficult to implement this but it takes a few changes in
> > at least three packages. It also requires learning a bit about PDF so
> > you can extend the PDF library accordingly. HTH
> >
> > On 11.07.2008 14:27:59 Jiri Tyr wrote:
> >> So it is necessary to create some special interface for this purpose? I
> >> mean some general interface for input from a config file and from FO
> >> file. If this interface exists it should not be difficult to change any
> >> property from users Java program.
> >>
> >> How difficult it can be to implement such think in FOP? If somebody have
> >> a time to sketch out the solution, it would be great.
> >>
> >> Jiri
> >>
> >>
> >> Jeremias Maerki wrote:
> >>> Yes, the FO spec allows that. Please realize that some people want one
> >>> feature to be configurable in the config file. Others want to access it
> >>> programmatically. And others want to include it in the FO file. Often we
> >>> end up doing the same in more than one places.
> >>>
> >>> On 11.07.2008 12:27:09 Justus-bulk wrote:
> >>>> Are processor-specific fo extensions really the generally-accepted way
> >>>> to go? I'd hesitate because this requires processor-specific XSLT
> >>>> customizations. Are there really no better ways to to pass
> >>>> document-specific parameters to the FO processor: command-line
> >>>> options, .properties files, ...
> >>>>
> >>>> Justus
> >>>
> >>> Jeremias Maerki

Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Jiri Tyr]

And could you forward this our conversation to the fop-dev mailing list?
Maybe somebody could implement it faster and better than me.

Jeremias Maerki wrote:

> I'll defer to the interested parties to design that. I haven't looked
> into what would be necessary to have. But design work should probably be
> done over on fop-dev@....
>
> On 11.07.2008 15:22:03 Jiri Tyr wrote:
>> Can you send me some example of FO with the fox:pdf-catalog example?
>> Then I could try to investigate if I can clone and modify the XMP for
>> this purpose.
>>
>> Jiri
>>
>>
>> Jeremias Maerki wrote:
>>> Take a look at the XMP metadata extension which is quite similar to
>>> what's necessary here:
>>> src/java/org/apache/fop/fo/extensions/xmp/*.java
>>> The PDFRenderer has to be extended, too, to catch the
>>> ExtensionAttachment subclass for the extension and react on it.
>>>
>>> It's not too difficult to implement this but it takes a few changes in
>>> at least three packages. It also requires learning a bit about PDF so
>>> you can extend the PDF library accordingly. HTH
>>>
>>> On 11.07.2008 14:27:59 Jiri Tyr wrote:
>>>> So it is necessary to create some special interface for this purpose? I
>>>> mean some general interface for input from a config file and from FO
>>>> file. If this interface exists it should not be difficult to change any
>>>> property from users Java program.
>>>>
>>>> How difficult it can be to implement such think in FOP? If somebody have
>>>> a time to sketch out the solution, it would be great.
>>>>
>>>> Jiri
>>>>
>>>>
>>>> Jeremias Maerki wrote:
>>>>> Yes, the FO spec allows that. Please realize that some people want one
>>>>> feature to be configurable in the config file. Others want to access it
>>>>> programmatically. And others want to include it in the FO file. Often we
>>>>> end up doing the same in more than one places.
>>>>>
>>>>> On 11.07.2008 12:27:09 Justus-bulk wrote:
>>>>>> Are processor-specific fo extensions really the generally-accepted way
>>>>>> to go? I'd hesitate because this requires processor-specific XSLT
>>>>>> customizations. Are there really no better ways to to pass
>>>>>> document-specific parameters to the FO processor: command-line
>>>>>> options, .properties files, ...

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Jeremias Maerki-2]

On 11.07.2008 15:52:12 Jiri Tyr wrote:
> And could you forward this our conversation to the fop-dev mailing list?

Not necessary as all committers are required to be on fop-users, too.
They can look this up.

> Maybe somebody could implement it faster and better than me.

Maybe. But you might not find anyone with the time and motivation to do
it. It always boils down to the three options of Open Source:
   1. This is open source software, you can do it yourself.
   2. This is open source software, you can wait until someone has free time and thinks this is fun to implement.
   3. Or you can find/hire someone to do it for you.
;-)

> Jeremias Maerki wrote:
> > I'll defer to the interested parties to design that. I haven't looked
> > into what would be necessary to have. But design work should probably be
> > done over on fop-dev@....
> >
> > On 11.07.2008 15:22:03 Jiri Tyr wrote:
> >> Can you send me some example of FO with the fox:pdf-catalog example?
> >> Then I could try to investigate if I can clone and modify the XMP for
> >> this purpose.
> >>
> >> Jiri
> >>
> >>
> >> Jeremias Maerki wrote:
> >>> Take a look at the XMP metadata extension which is quite similar to
> >>> what's necessary here:
> >>> src/java/org/apache/fop/fo/extensions/xmp/*.java
> >>> The PDFRenderer has to be extended, too, to catch the
> >>> ExtensionAttachment subclass for the extension and react on it.
> >>>
> >>> It's not too difficult to implement this but it takes a few changes in
> >>> at least three packages. It also requires learning a bit about PDF so
> >>> you can extend the PDF library accordingly. HTH
> >>>
> >>> On 11.07.2008 14:27:59 Jiri Tyr wrote:
> >>>> So it is necessary to create some special interface for this purpose? I
> >>>> mean some general interface for input from a config file and from FO
> >>>> file. If this interface exists it should not be difficult to change any
> >>>> property from users Java program.
> >>>>
> >>>> How difficult it can be to implement such think in FOP? If somebody have
> >>>> a time to sketch out the solution, it would be great.
> >>>>
> >>>> Jiri
> >>>>
> >>>>
> >>>> Jeremias Maerki wrote:
> >>>>> Yes, the FO spec allows that. Please realize that some people want one
> >>>>> feature to be configurable in the config file. Others want to access it
> >>>>> programmatically. And others want to include it in the FO file. Often we
> >>>>> end up doing the same in more than one places.
> >>>>>
> >>>>> On 11.07.2008 12:27:09 Justus-bulk wrote:
> >>>>>> Are processor-specific fo extensions really the generally-accepted way
> >>>>>> to go? I'd hesitate because this requires processor-specific XSLT
> >>>>>> customizations. Are there really no better ways to to pass
> >>>>>> document-specific parameters to the FO processor: command-line
> >>>>>> options, .properties files, ...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@...
> For additional commands, e-mail: fop-users-help@...

Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...

[Jiri Tyr]

OK, I understand. Could you then send me some XPM demo and your
imagination how should be the fox:pdf-catalog implemented in FO file?
Then I will try to implement it by my self or find/hire somebody who
could do it for me ;o)

Jeremias Maerki wrote:

> On 11.07.2008 15:52:12 Jiri Tyr wrote:
>> And could you forward this our conversation to the fop-dev mailing list?
>
> Not necessary as all committers are required to be on fop-users, too.
> They can look this up.
>
>> Maybe somebody could implement it faster and better than me.
>
> Maybe. But you might not find anyone with the time and motivation to do
> it. It always boils down to the three options of Open Source:
>    1. This is open source software, you can do it yourself.
>    2. This is open source software, you can wait until someone has free time and thinks this is fun to implement.
>    3. Or you can find/hire someone to do it for you.
> ;-)
>
>> Jeremias Maerki wrote:
>>> I'll defer to the interested parties to design that. I haven't looked
>>> into what would be necessary to have. But design work should probably be
>>> done over on fop-dev@....
>>>
>>> On 11.07.2008 15:22:03 Jiri Tyr wrote:
>>>> Can you send me some example of FO with the fox:pdf-catalog example?
>>>> Then I could try to investigate if I can clone and modify the XMP for
>>>> this purpose.
>>>>
>>>> Jiri
>>>>
>>>>
>>>> Jeremias Maerki wrote:
>>>>> Take a look at the XMP metadata extension which is quite similar to
>>>>> what's necessary here:
>>>>> src/java/org/apache/fop/fo/extensions/xmp/*.java
>>>>> The PDFRenderer has to be extended, too, to catch the
>>>>> ExtensionAttachment subclass for the extension and react on it.
>>>>>
>>>>> It's not too difficult to implement this but it takes a few changes in
>>>>> at least three packages. It also requires learning a bit about PDF so
>>>>> you can extend the PDF library accordingly. HTH
>>>>>
>>>>> On 11.07.2008 14:27:59 Jiri Tyr wrote:
>>>>>> So it is necessary to create some special interface for this purpose? I
>>>>>> mean some general interface for input from a config file and from FO
>>>>>> file. If this interface exists it should not be difficult to change any
>>>>>> property from users Java program.
>>>>>>
>>>>>> How difficult it can be to implement such think in FOP? If somebody have
>>>>>> a time to sketch out the solution, it would be great.
>>>>>>
>>>>>> Jiri
>>>>>>
>>>>>>
>>>>>> Jeremias Maerki wrote:
>>>>>>> Yes, the FO spec allows that. Please realize that some people want one
>>>>>>> feature to be configurable in the config file. Others want to access it
>>>>>>> programmatically. And others want to include it in the FO file. Often we
>>>>>>> end up doing the same in more than one places.
>>>>>>>
>>>>>>> On 11.07.2008 12:27:09 Justus-bulk wrote:
>>>>>>>> Are processor-specific fo extensions really the generally-accepted way
>>>>>>>> to go? I'd hesitate because this requires processor-specific XSLT
>>>>>>>> customizations. Are there really no better ways to to pass
>>>>>>>> document-specific parameters to the FO processor: command-line
>>>>>>>> options, .properties files, ...

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@...
For additional commands, e-mail: fop-users-help@...