RE: PDF that is printed and folded
You may be able to do the rearranging with iText. -Original Message- From: Sönke Ruempler [mailto:[EMAIL PROTECTED] Sent: Friday, December 10, 2004 10:24 AM To: [EMAIL PROTECTED] Subject: PDF that is printed and folded Hi, I'm creating a flyer filled with events using fop. It's a A3 formatted page with 4 columns printed on both sides. After the flyer is printed, it's folded in the middle (to A4) and the order of pages changes. The start page (the first column of the original first page) is now the the first row of the back page. Do you understand me? ;-) If not, i can draw a little graphic. Is there a solution for ordering the rows/pages after their generation? -- soenke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Border issue
I was using Acrobat Standard Edition 6.0.1. I also tried it on Acrobat Reader v5.0.5 on another machine. Same results for me, bleeding still occurs. Were you zooming all the way in on the edge of the cell? Although it is not bad in this example file, with a table border turned on, the problem looks much worse. The blue background overwrites the outside table border. -Original Message- From: John Burgess [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 5:20 AM To: [EMAIL PROTECTED] Subject: Re: Border issue Matthew Either I'm being even more stupid than usual or there's a problem with your acrobat reader. In the pdf you attached on my machine (NT4 (SP4) and Acrobat 5.0.0 the blue colour is perfectly contained in the cell. I think the Standard Error text seems a little high in the cell below but since you're not complaining about that... Have you tried it on another machine? John - Original Message - From: Zaleski, Matthew (M.E.) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 03, 2004 8:19 PM Subject: FW: Border issue /bump -Original Message- From: Zaleski, Matthew (M.E.) Sent: Thursday, July 29, 2004 4:57 PM To: [EMAIL PROTECTED] Subject: RE: Border issue Ok, I've stripped my example down even further. I've eliminated all padding attributes. I have background-color enabled on a single cell. I also am now using borders only on table-cell elements. I turned off the outside border on the table in case it was a problem. In the new example attached here, the background color is clearly bleeding all over the place (especially since I set it only for a single cell). I can see no attributes left in my XSL-FO to explain it. If I move background-color to the fo:block, the pattern is the same. My understanding of the XSL-FO spec was that padding pushed out beyond the borders and that was why you suggested eliminating padding. Is there any hope of using background color (or a workaround that achieves the same effect) in 0.20.5? Your response seems to indicate that I should not be seeing this behavior. -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 28, 2004 5:11 PM To: [EMAIL PROTECTED] Subject: Re: Border issue Zaleski, Matthew (M.E.) wrote: Thanks for the answer. What is the proper workaround for not using padding? I need to keep space between my blocks and the borders of the cells. Some of the cells have single blocks, some have multiple blocks (like the header row). Enclose the content in yet another block, and try to use space-before/space-start/whatever on this block. Padding might work in this case. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FW: Border issue
Thanks. That's the clue I needed. When I set the cell border to 0.2mm (as opposed to 0.02mm), the background does not bleed in the last example I posted. I will do more experiments, this time working with my original XSLT stylesheet (which outputs a roughly 160kb FO file), and see if that corrects my problem. If that fixes it, I will post the answer here so that the solution makes it into the list archive. This may be a candidate for the existing FAQs on the FOP website. -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 03, 2004 4:39 PM To: [EMAIL PROTECTED] Subject: Re: FW: Border issue Zaleski, Matthew (M.E.) wrote: Is there any hope of using background color (or a workaround that achieves the same effect) in 0.20.5? Your response seems to indicate that I should not be seeing this behavior. I have no idea. A border width of 0.02mm very small though, you might run into roundoff problems (one of Acrobat Reader's most infamous weak point...) J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: Border issue
/bump -Original Message- From: Zaleski, Matthew (M.E.) Sent: Thursday, July 29, 2004 4:57 PM To: [EMAIL PROTECTED] Subject: RE: Border issue Ok, I've stripped my example down even further. I've eliminated all padding attributes. I have background-color enabled on a single cell. I also am now using borders only on table-cell elements. I turned off the outside border on the table in case it was a problem. In the new example attached here, the background color is clearly bleeding all over the place (especially since I set it only for a single cell). I can see no attributes left in my XSL-FO to explain it. If I move background-color to the fo:block, the pattern is the same. My understanding of the XSL-FO spec was that padding pushed out beyond the borders and that was why you suggested eliminating padding. Is there any hope of using background color (or a workaround that achieves the same effect) in 0.20.5? Your response seems to indicate that I should not be seeing this behavior. -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 28, 2004 5:11 PM To: [EMAIL PROTECTED] Subject: Re: Border issue Zaleski, Matthew (M.E.) wrote: Thanks for the answer. What is the proper workaround for not using padding? I need to keep space between my blocks and the borders of the cells. Some of the cells have single blocks, some have multiple blocks (like the header row). Enclose the content in yet another block, and try to use space-before/space-start/whatever on this block. Padding might work in this case. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mztest2.fo Description: mztest2.fo mztest2.pdf Description: mztest2.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Border issue
Ok, I've stripped my example down even further. I've eliminated all padding attributes. I have background-color enabled on a single cell. I also am now using borders only on table-cell elements. I turned off the outside border on the table in case it was a problem. In the new example attached here, the background color is clearly bleeding all over the place (especially since I set it only for a single cell). I can see no attributes left in my XSL-FO to explain it. If I move background-color to the fo:block, the pattern is the same. My understanding of the XSL-FO spec was that padding pushed out beyond the borders and that was why you suggested eliminating padding. Is there any hope of using background color (or a workaround that achieves the same effect) in 0.20.5? Your response seems to indicate that I should not be seeing this behavior. -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 28, 2004 5:11 PM To: [EMAIL PROTECTED] Subject: Re: Border issue Zaleski, Matthew (M.E.) wrote: Thanks for the answer. What is the proper workaround for not using padding? I need to keep space between my blocks and the borders of the cells. Some of the cells have single blocks, some have multiple blocks (like the header row). Enclose the content in yet another block, and try to use space-before/space-start/whatever on this block. Padding might work in this case. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mztest2.fo Description: mztest2.fo mztest2.pdf Description: mztest2.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: LPI and CPI vs line-height and font-size
Hrmm. What version of Acrobat are you running? I have Acrobat Standard 6.0 (the one you pay for) and Ctrl-U does nothing. I wandered through the preferences and menus and found nothing to give me a grid. -Original Message- From: john farrow [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 27, 2004 6:21 PM To: [EMAIL PROTECTED] Subject: Re: LPI and CPI vs line-height and font-size That looks like a problem with FOP. By setting line-height=0.125in you should get 8 lines per inch. If you have Acrobat you can press control-U which brings up the grid, so you can measure things without needing to print them. Regards John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Border issue
Thanks for the answer. What is the proper workaround for not using padding? I need to keep space between my blocks and the borders of the cells. Some of the cells have single blocks, some have multiple blocks (like the header row). -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 28, 2004 4:20 PM To: [EMAIL PROTECTED] Subject: Re: Border issue Zaleski, Matthew (M.E.) wrote: Look at the line with the light blue background. The borders on extreme left are right edge are getting overwritten by the background color. (the background color is bleeding on the top as well.) I'm doing nested tables for layout purposes. I've tried having the outside border be generated by the fo:table and (in this example) the enclosing fo:table-cell element. The problem doesn't change. That's a known problem. Don't use padding. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Border issue
I saw a recent post to the list that had a slightly different problem than I'm experiencing. I hope attachments go through to the list. My .fo file is being generated via XSLT and is usually 150k to 200k in size. I've managed to pare it down to 13k and still have the problem visible. My apologies for it even being that large. Look at the line with the light blue background. The borders on extreme left are right edge are getting overwritten by the background color. (the background color is bleeding on the top as well.) I'm doing nested tables for layout purposes. I've tried having the outside border be generatedby the fo:table and (in this example) the enclosing fo:table-cell element. The problem doesn't change. Am I making a newbie mistake or is this a fundamental problem in FOP 0.20.5? If it is a "feature" in 0.20.5, are there any known workarounds? Thanks, Matthew Zaleski ?xml version=1.0 encoding=utf-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=only page-height=11in page-width=8.5in margin-top=0in margin-bottom=0in margin-left=0in margin-right=0in fo:region-body region-name=xsl-region-body margin-top=0.5in margin-bottom=0.8in margin-left=0.5in margin-right=0.5in/ fo:region-before region-name=xsl-region-before extent=0.7in display-align=before/ fo:region-after region-name=xsl-region-after extent=0.7in display-align=after/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=only fo:static-content flow-name=xsl-region-before /fo:static-content fo:static-content flow-name=xsl-region-after /fo:static-content fo:flow flow-name=xsl-region-body fo:table table-layout=fixed width=7.5in space-before=18pt fo:table-column column-width=1.5625in/ fo:table-column column-width=4.375in/ fo:table-column column-width=1.5625in/ fo:table-body fo:table-row fo:table-cell/ fo:table-cell fo:block text-align=center font-family=Helvetica font-size=14pt font-weight=boldTable 1/fo:block /fo:table-cell fo:table-cell/ /fo:table-row fo:table-row keep-with-previous=20 fo:table-cell/ fo:table-cell border-style=solid border-width=0.4mm fo:table table-layout=fixed font-family=Helvetica font-size=9pt width=4.375in fo:table-column column-width=2in/ fo:table-column column-width=proportional-column-width(1)/ fo:table-column column-width=proportional-column-width(1)/ fo:table-body fo:table-row font-weight=bold fo:table-cell padding-top=2pt padding-bottom=0pt padding-left=2pt padding-right=2pt border-style=solid border-width=0.02mm display-align=after text-align=center fo:block Column 1 /fo:block /fo:table-cell fo:table-cell padding-top=2pt padding-bottom=0pt padding-left=2pt padding-right=2pt border-style=solid border-width=0.02mm display-align=after text-align=center fo:blockColumn 2/fo:block fo:block(subtitle)/fo:block /fo:table-cell fo:table-cell padding-top=2pt padding-bottom=0pt padding-left=2pt padding-right=2pt border-style=solid border-width=0.02mm display-align=after text-align=center fo:blockColumn 3/fo:block fo:block(subtitle)/fo:block /fo:table-cell /fo:table-row fo:table-row keep-with-previous=10 fo:table-cell padding-top=2pt padding-bottom=0pt padding-left=2pt padding-right=2pt border-style=solid border-width=0.02mm display-align=after fo:blockrun 1fo:inline color=red ***/fo:inline /fo:block /fo:table-cell fo:table-cell padding-top=2pt padding-bottom=0pt padding-left=2pt padding-right=2pt border-style=solid border-width=0.02mm display-align=after text-align=right end-indent=.47in fo:blockL/fo:block /fo:table-cell fo:table-cell padding-top=2pt padding-bottom=0pt padding-left=2pt padding-right=2pt border-style=solid border-width=0.02mm display-align=after text-align=right end-indent=.39in fo:block3.93/fo:block /fo:table-cell /fo:table-row
RE: external-graphic src problem
This possibly becomes an XSLT problem. Use a global variable passed into the XSLT transform to provide the basedir for the images. -Original Message- From: Danny [mailto:[EMAIL PROTECTED] Sent: Friday, July 23, 2004 9:56 AM To: [EMAIL PROTECTED] Subject: RE: external-graphic src problem Clay, I did read up on some of the baseDir mails on various lists. Using baseDir I could reference the relative path to the image in the xsl, but I would have to specify an absolute path in the baseDir, so really that is the same as just hardcoding the path in the xsl. My problem is that I do not want to require the application be installed in a specific directory structure, although, if that is the only way perhaps that is what I need to do. If I find a solution I will post it back. Thanks for the help. Danny Gallagher Senior Software Engineer The Gainer Group 6075 The Corners Parkway Suite 116 Norcross Ga, 30092 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: external-graphic src problem
If you are streaming XML, then how do you have a classpath to consider?
Your responses up to this point imply that a CLIENT is receiving XML
from a DB, then running an XSLT transform, followed up by FOP
processing. If this is the case, your client-side processing can
determine where the images reside and pass a global variable into the
XSLT transform.
If the DB you refer to is on the same machine, then again you know where
the images reside.
I think you are confusing the fact that FOP happens to be coded in Java
as a reason why FOP should be searching CLASSPATH for images. FOP is
following XSL-FO rules for processing, not Java-centric rules for
CLASSPATH. Since you are aware of what a CLASSPATH is, I assume you can
code in Java. Assuming that is true, then it is but a small step for
your client application to pass in a global variable to the XSLT engine
you are using.
Then again, I really don't understand your problem domain.
-Original Message-
From: Danny [mailto:[EMAIL PROTECTED]
Sent: Friday, July 23, 2004 2:38 PM
To: [EMAIL PROTECTED]
Subject: RE: external-graphic src problem
So in my case, because the xml is streamed from the db and therefore
doesn't reside in a directory I have no base to specify the relative
path to the image from, which in most cases would be the XML file's
directory?
Danny Gallagher
Senior Software Engineer
The Gainer Group
6075 The Corners Parkway
Suite 116
Norcross Ga, 30092
-Original Message-
From: Clay Leeds [mailto:[EMAIL PROTECTED]
Sent: Friday, July 23, 2004 1:48 PM
To: [EMAIL PROTECTED]
Subject: Re: external-graphic src problem
On Jul 23, 2004, at 10:40 AM, Danny wrote:
Still not quite, I'm still missing something:
Question, in your example:
xsl:variable name=varImagesDirectory/path/to/images/xsl:variable
/path/to/images is the path from a known root Correct?
That is correct. Otherwise...
Here are my snippets
xsl:variable name=varImagesDirectory
com/path/to/images
/xsl:variable
fo:external-graphic src=url('{$varImagesDirectory}/pic.jpg')
/fo:external-graphic
...(if I understand it correctly) would assume
{XML-dir}/com/path/to/images/pic.jpg
Web Maestro Clay
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: List problem
keep-with-next, keep-with-previous do work for table rows. That is part of the reason why I now have multi-layered tables in my .fo files. It's a bit slow but it works. From: Raphael Parree (Triveratech) [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 13, 2004 1:45 PMTo: [EMAIL PROTECTED]Subject: RE: List problem No particular reason for using list other than what I need is what a list offers (in XSL-FO spec). I will consider refractoring it to a table, however tables make my transformation slow. Does someone know how this is resolved in a next version of FOP. Also will keep-with next etc be supported? tx., Raphaël Parrée Director Courseware Consulting Services Principal Consultant Direct phone: +33 498 050075 Voice mail +33 683 468663 Trivera Technologies Global J2EE Education, Mentoring, Courseware Consulting Services Trivera Technologies EMEAA Trivera Technologies Europe, Middle East, Africa USA Canada Asia Pacific P +33 442 163594 P 1 609 953 1515 F +33 442 163509 F +1 609 953 6886 Espace Cézanne 135 Meeshaway Trail 14, Parc Golf du Club Medford Lakes 13856 Aix-en-Provence (France) NJ08055 (USA) URL http://www.triveratech.com Disclaimer .. "This email transmission (including attachments, if any) is confidential and intended solely for the person or organization to whom it is addressed and may contain information that is privileged, proprietary or confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any distribution, dissemination or copying of the information is strictly prohibited including taking any action in reliance of it. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of any organization or employer. If you wish to forward or otherwise use all of part of the content of this message, you need sender's written permission prior to forwarding or using the content. If you have received this message in error, do not open any attachment but please notify the sender (above) deleting this message from your system. Please rely on your own virus checking, no responsibility is taken by the sender for any damage rising out of any bug or virus infection." -Original Message-From: Zaleski, Matthew (M.E.) [mailto:[EMAIL PROTECTED]Sent: Friday, July 09, 2004 20:31To: [EMAIL PROTECTED]; [EMAIL PROTECTED]Subject: RE: List problem Any particular reason you don't just make a table with 2 columns, the first column being your fo:list-item-label body? It may get around certain limitations in fop 0.20.5. A few other comments on your tables from my recent dive into using them: fo:table width="100%" is not supported AFAICT in fop 0.20.5. I have to specify exact width in inches/mm/etc to avoid getting a warning. Your fo:table-column column-number="1" (column-number attrib not supported in fop), use fo:table-column column-width="proportional-column-width(1)"/ and provide column entries in left to right order. In general, I've found that tables don't like to play nice with other enclosing elements and now have heavily nested tables to preserve layouts on my pages. It slows down processing but I get the layouts in my PDFs that I want. From: Raphael Parree (Triveratech) [mailto:[EMAIL PROTECTED] Sent: Thursday, July 08, 2004 3:48 PMTo: [EMAIL PROTECTED]Subject: List problem Hi I am having a problem making a list. I am using the XSL below to create a list. fo:list-item fo:list-item-label fo:block end-indent="label-end()"-/fo:block /fo:list-item-label fo:list-item-body start-indent="body-start()" fo:block fo:table width="100%" table-layout="fixed" fo:table-column column-number="1"/ fo:table-body fo:table-row keep-together="always" fo:table-cell fo:block xsl:apply-templates select="FOO"/ xsl:apply-templates select="BAR"/ /fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:block /fo:list-item-body /fo:list-item What happens sometimes is that the - w/out any body is on one page and the body is on the next page without a -. Any ideas? Tx., Raphael image001.gifimage002.gif
RE: List problem
Any particular reason you don't just make a table with 2 columns, the first column being your fo:list-item-label body? It may get around certain limitations in fop 0.20.5. A few other comments on your tables from my recent dive into using them: fo:table width="100%" is not supported AFAICT in fop 0.20.5. I have to specify exact width in inches/mm/etc to avoid getting a warning. Your fo:table-column column-number="1" (column-number attrib not supported in fop), use fo:table-column column-width="proportional-column-width(1)"/ and provide column entries in left to right order. In general, I've found that tables don't like to play nice with other enclosing elements and now have heavily nested tables to preserve layouts on my pages. It slows down processing but I get the layouts in my PDFs that I want. From: Raphael Parree (Triveratech) [mailto:[EMAIL PROTECTED] Sent: Thursday, July 08, 2004 3:48 PMTo: [EMAIL PROTECTED]Subject: List problem Hi I am having a problem making a list. I am using the XSL below to create a list. fo:list-item fo:list-item-label fo:block end-indent="label-end()"-/fo:block /fo:list-item-label fo:list-item-body start-indent="body-start()" fo:block fo:table width="100%" table-layout="fixed" fo:table-column column-number="1"/ fo:table-body fo:table-row keep-together="always" fo:table-cell fo:block xsl:apply-templates select="FOO"/ xsl:apply-templates select="BAR"/ /fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:block /fo:list-item-body /fo:list-item What happens sometimes is that the - w/out any body is on one page and the body is on the next page without a -. Any ideas? Tx., Raphael
RE: List problem
You are probably right. I know I just had a lot of problems with FOP's missing FO element/attributes during my fo:table trials and tribulations. It's not a big deal on the column-width attribute since proportional-column-width() is implemented. IIRC, I wanted a horizontally centered table, which was not possible without resorting to nested tables. That issue made width=xx% moot since I had to drive the width's with XSL variables calculated at runtime. -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Friday, July 09, 2004 5:06 PM To: [EMAIL PROTECTED] Subject: Re: List problem Zaleski, Matthew (M.E.) wrote: A few other comments on your tables from my recent dive into using them: fo:table width=100% is not supported AFAICT in fop 0.20.5. Percentages are supported in many places, including the width property. It's not supported in column-widths. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with transformation
This question seems to fall into an XSLT category rather than XSL-FO. One comment I would make is that the structure of your XML is weak. If picture1 and description1 belong together, the xml should indicate that. You could add a another layer like this list list-item list-labelpicture1.eps/list-label list-textdescription1/list-text /list-item list-item list-labelpicture2.eps/list-label list-textdescription2/list-text /list-item /list Or you could make 'label' or 'text' an attribute of the other. I don't know the details of your problem domain so you would have to make the determination. If your xml format is locked, then you need to look at using the sibling axis in Xpath to get some association between the labels and the text. That question belongs in an XSLT list though. -Original Message- From: Johan Andersson [mailto:[EMAIL PROTECTED] Sent: Friday, June 18, 2004 4:06 AM To: Apache FOP Mailinglist Subject: Problem with transformation Hi all, I'm trying to transform the XML snippet below to a FO table with a width of 3 columns. The list contain a maximum of 9 elements. Each cell should contain an image and its description. I would appreciate any advice on how to implement such a transformation. snippet ... list list-labelpicture1.eps/list-label list-textdescription/list-text list-labelpicture2.eps/list-label list-textdescription/list-text list-labelpicture3.eps/list-label list-textdescription/list-text list-labelpicture4.eps/list-label list-textdescription/list-text ... /list ... /snippet Regards, Johan Andersson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
