Re: PNG transparency renders as black - urgent
...just to keep the track - I applied your patch as you posted it, worked nice for all my PNGs (but I didn't explicitly tested various png types); Thanks for the help! Martin Jeremias Maerki wrote: Actually, this is so simple, I've created a patch. I'm hesitant to apply it without much testing with various PNGs for which I have no time right now. But maybe one of you can take a look. If it's good JAIImage and JimiImage could be similarly patched. On 19.12.2006 23:01:36 Jeremias Maerki wrote: It turns out the following revision is responsible for the regression: http://svn.apache.org/viewvc?rev=424349view=rev Putting the Commons codec before the ImageIO variant in ImageFactory is a quick fix for this. I originally switched because of speed reasons but obviously I didn't test PNGs with alpha channel. The reason why Martin's PNG doesn't work with the ImageIOImage class is the lack of support for java.awt.Transparency.TRANSLUCENT. If it were a BITMASK it would work. The same problem exists for JAIImage and JimiImage, BTW. Again, this is something a complete redesign of the image package would have addressed. It's on my higher priority list but I still haven't got to it, yet. If someone wants to try to implement that little code that is missing as a temporary fix, please do. It shouldn't be difficult. You can maybe use XmlGraphicsCommonsImage for hints. On 19.12.2006 20:30:35 Andreas L Delmelle wrote: On Dec 19, 2006, at 19:56, Peter wrote: When working on the patch I certainly can not remember coming anywhere close to code that could have an influence on how png's get into the pdf. I was also a bit puzzled, since in the patch there are no explicit references to anything png-related (IIC, png-related stuff is already put in Commons for that matter, so it couldn't have been touched directly by the patch) OTOH, this was the only significant change to the codebase between 13.11 and now, so one can reasonably assume that the cause is in there somewhere... I'd expect something which has an impact on the interaction with the commons-lib? Cheers, Andreas Jeremias Maerki Jeremias Maerki - 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: PNG transparency renders as black - urgent
...just to point out that I used the same image with the FOP binary from November 13th, and the result was *ok*. What changed between these versions??? Also I tried to convert to indexed colors with transparency (in photoshop) and it also works. But full PNG (RGB, 24-bit) with transparency doesn't. We updated fop (for various reasons) on the client server and got to this bad situation :(( it's urgent otherwise they will chop my head off :| cheers Martin Martin Zak wrote: Hi all, really I'm the only one who came to this issue?? Any feedback is welcomed... Thanks Martin Original Message Subject: PNG transparency renders as black Date: Thu, 07 Dec 2006 16:09:18 +0100 From: Martin Zak [EMAIL PROTECTED] Reply-To: fop-users@xmlgraphics.apache.org, [EMAIL PROTECTED] Organization: Ginger Alliance To: fop-users@xmlgraphics.apache.org Hi all, I had to go for a trunk version of FOP due to some fixes available in this version. Unfortunately it seems I came to the bug which was introduced in some of the new versions. When including PNG image containing transparent areas (using fo:external-graphic), the image is corrupted. The transparent area is rendered in black and also the image itself seems to doubled while shifted down (see the sample). I used the same image with the FOP binary from November 13th, and the result was ok. Also the size of the resulting pdf differs a lot (141kB with old/correct version against 37kB with new/wrong). (BTW how do I find the build version when fop says FOP Version svn-trunk ?? Where to look for the version info?) Any idea what could change? (we use fop in production and got to troubles after the update :| ) Files: png_transparency.fo test.png png_transparency_good.pdf [pdf generated with fop trunk of November 13th] png_transparency_wrong.pdf[pdf generated with fop trunk of today (December 7th)] Cheers Martin - 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: absolutely positioned block-container issue
I just would like to remind this issue - I created the bug report under #39968. Would it be difficult to fix it? It would be great to have it soon (otherwise you will loose one FOP user as my client will chop my head off :| ). Thanks cheers Martin Zak Chris Bowditch wrote: Martin Zak wrote: ... I evaluated the conditional spacing, but when I retain the space-before, the blocks will have the spacing which doesn't match the strict client requirements. (e.g. title has a 9pt space-after and following block 6pt space-before, which would - of course - lead us to 15pt of total space between, which is bad. I can't simply remove the space-before (or after), as the document structure is so complex it would lead to wrong results in certain combination of blocks) :( It seems I'll have to wait for your fix... So this bug isn't forgotten can you raise a bug report in Bugzilla please? Following the link below to do it: http://xmlgraphics.apache.org/fop/bugs.html snip/ thanks, Chris - 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: absolutely positioned block-container issue
... I evaluated the conditional spacing, but when I retain the space-before, the blocks will have the spacing which doesn't match the strict client requirements. (e.g. title has a 9pt space-after and following block 6pt space-before, which would - of course - lead us to 15pt of total space between, which is bad. I can't simply remove the space-before (or after), as the document structure is so complex it would lead to wrong results in certain combination of blocks) :( It seems I'll have to wait for your fix... Cheers Martin Jeremias Maerki wrote: Not sure if it'll fit into this week. I'm leaving for Ireland on Thursday and won't have much time for hacking until 2006-07-08. But did you look at Chris' suggestion about conditional spacing? Doesn't that help you for the moment? On 19.06.2006 18:12:21 Martin Zak wrote: ...thanks Jeremias, I thought the reason to be like that. But there is a question (as always :) ) - would you care to fix it ? (with respect to importance you assigned to it mentally) In case it would not be so big change, when do you expect it? [just to provide some background of this issue: I render the book without side-notes in 'normal' mode and with side-notes in 'review' mode (where side-notes contain the link for editing paras. Obviously it is VERY bad these two pages doesn't look the same. I was trying to find some workaround, but no luck till now. I'm stuck with big project :(( ] anyway, thanks for the amazing work! Martin Jeremias Maerki wrote: On 16.06.2006 15:07:25 Chris Bowditch wrote: Martin Zak wrote: Hi all, I'm using the absolutely positioned block-container for a side-note. The page body has left margin defined while block-container has start-indent set to 0pt. (so the block-container is rendered in a column left to the rest of the text on page like this: snip/ fo:page-sequence format=1 master-reference=sequence-chapter fo:flow font-family=Times font-size=12pt flow-name=xsl-region-body margin-left=1.37in fo:block-container margin=0pt padding=0pt width=30pt start-indent=0pt absolute-position=absolute fo:block[abs]/fo:block /fo:block-container fo:block space-before=9ptlorem ipsum dolores.../fo:block Whats happening here is the rules of conditional spacing. If a space is the first in the reference area (fo:flow in your example) then the default is to discard the space. If the space is not the first thing in a reference area then its is retained. It seems the block-container fools FOP into thinking that there is something before the space in the reference area and it is therefore retained. Indeed, the BlockContainerLayoutManager creates a KnuthBox (w=0) in the element list for the absolutely positioned block-container which is currently interpreted by the SpaceResolver as a fence. And a fence makes the SpaceResolver believe that there's content before the space. Looks like we should find a solution to indicate to the SpaceResolver which boxes are no fences. Another example would be the often-used empty block at the end of the flow for page x of y which probably creates a fence, too. Without knowing the full context of your application I'm not sure of a wrokaround. Specifying space-before.conditionality=retain will ensure the space is always shown, regardless of whether there is a block container or not. snip/ Chris Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Martin Zak project manager, developer Ginger Alliance, s.r.o. Otakarova 15 140 00 Prague Czech Republic Office: tel +420 241 741 406 : fax +420 241 740 398 YM ID : zakmart Email : [EMAIL PROTECTED] http://www.gingerall.com http://www.ga-mme.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
absolutely positioned block-container issue
Hi all, I'm using the absolutely positioned block-container for a side-note. The page body has left margin defined while block-container has start-indent set to 0pt. (so the block-container is rendered in a column left to the rest of the text on page like this: Page Heading [side-note]page text sample page text sample page text sample page text and more page text more page text It works nice, until following situation occurs: the block following the absolutely positioned block-container has space-before property defined. Then this property applies and the (second) block is shifted down from the block-container. When I remove the block-container, this property doesn't apply any more... It seems the absolutely positioned block-container affects the layout in normal text flow. Is it a bug or I just miss something in layout rules? I would be happy for any help as my big project is stuck due to this issue :( Thanks Martin Zak fop 0.92beta -- code snippet: fo:flow font-family=Times font-size=12pt flow-name=xsl-region-body margin-left=1.37in fo:block-container margin=0pt padding=0pt width=30pt start-indent=0pt absolute-position=absolute fo:block[abs]/fo:block /fo:block-container fo:block space-before=9ptlorem ipsum dolores.../fo:block /fo:flow --- attachments: absolute-position_no-container.pdf absolute-position_with-container.pdf absolute-position.fo --- -- Martin Zak project manager, developer Ginger Alliance, s.r.o. Otakarova 15 140 00 Prague Czech Republic Office: tel +420 241 741 406 : fax +420 241 740 398 YM ID : zakmart Email : [EMAIL PROTECTED] http://www.gingerall.com http://www.ga-mme.com absolute-position_no-container.pdf Description: Adobe PDF document absolute-position_with-container.pdf Description: Adobe PDF document ?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 margin-right=0.5in margin-left=0.5in margin-bottom=0.5in margin-top=0.5in page-width=8.5in page-height=11in master-name=chapter-page fo:region-body margin-left=0.5in margin-right=0.5in margin-top=0.5in margin-bottom=0.5in/ /fo:simple-page-master fo:page-sequence-master master-name=sequence-chapter fo:repeatable-page-master-alternatives fo:conditional-page-master-reference master-reference=chapter-page/ /fo:repeatable-page-master-alternatives /fo:page-sequence-master /fo:layout-master-set fo:page-sequence format=1 master-reference=sequence-chapter fo:flow font-family=Times font-size=12pt flow-name=xsl-region-body margin-left=1.37in fo:block-container margin=0pt padding=0pt width=30pt start-indent=0pt absolute-position=absolute fo:block[abs]/fo:block /fo:block-container fo:block space-before=9ptlorem ipsum dolores.../fo:block /fo:flow /fo:page-sequence /fo:root - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unresolved id reference on bookmarks
...sorry, fingers ahead of my head... it's 0.92beta and example is attached: Example contains single page with two block with 'id' attribute. When the bookmark id reference doesn't match any block with such id, no bookmarks are produced at all. When you change the id of second block or bookmark ref id to match each other, everything works ok. Cheers Martin === sample files: bookmarks_bug_wrong.fo - generates pdf with no bookmarks (wrong bookmark ref id) bookmarks_bug_wrong.pdf - corresponding pdf bookmarks_bug_correct.pdf - pdf with matching bookmark ref ids and block ids === Jeremias Maerki wrote: FOP version? Example? Thanks. On 06.06.2006 14:09:44 Martin Zak wrote: Hi all, I'm generating bookmarks bind to different elements in text while using the xsl generate-id() function to get unique id. When it comes to the situation one bookmark can't resolve the reference id (as such element with corresponding id doesn't exists - may occur in very complex document), FOP displays the warning: WARNING: Bookmarks: Unresolved id reference N10001 found. and _no_ bookmarks are produced to output PDF. IMHO when the doc contains hundreds of bookmarks and one is not valid, it may be skipped (or left with no reference?), but other bookmarks should be produced to output... I'm not sure whether it's just a sort of bug or desired behavior. If you know about some workaround, it would be welcomed! Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Martin Zak project manager, developer Ginger Alliance, s.r.o. Otakarova 15 140 00 Prague Czech Republic Office: tel +420 241 741 406 : fax +420 241 740 398 YM ID : zakmart Email : [EMAIL PROTECTED] http://www.gingerall.com http://www.ga-mme.com ?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 margin-right=1in margin-left=1in margin-bottom=1in margin-top=1in page-width=8.5in page-height=11in master-name=single-page fo:region-body margin-right=0in margin-left=0in margin-bottom=0in margin-top=0in/ /fo:simple-page-master fo:page-sequence-master master-name=single-sequence fo:single-page-master-reference master-reference=single-page/ /fo:page-sequence-master /fo:layout-master-set fo:bookmark-tree fo:bookmark internal-destination=dest_001 fo:bookmark-titledest_001 block/fo:bookmark-title /fo:bookmark fo:bookmark internal-destination=dest_002 fo:bookmark-titledest_002 block/fo:bookmark-title /fo:bookmark /fo:bookmark-tree fo:page-sequence master-reference=single-sequence fo:flow flow-name=xsl-region-body fo:block id=dest_001Block with id='dest_001'/fo:block fo:block id=dest_003Block with id='dest_003'/fo:block /fo:flow /fo:page-sequence /fo:root bookmarks_bug_correct.pdf Description: Adobe PDF document bookmarks_bug_wrong.pdf Description: Adobe PDF document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Unresolved id reference on bookmarks
Hi all, I'm generating bookmarks bind to different elements in text while using the xsl generate-id() function to get unique id. When it comes to the situation one bookmark can't resolve the reference id (as such element with corresponding id doesn't exists - may occur in very complex document), FOP displays the warning: WARNING: Bookmarks: Unresolved id reference N10001 found. and _no_ bookmarks are produced to output PDF. IMHO when the doc contains hundreds of bookmarks and one is not valid, it may be skipped (or left with no reference?), but other bookmarks should be produced to output... I'm not sure whether it's just a sort of bug or desired behavior. If you know about some workaround, it would be welcomed! Cheers Martin -- Martin Zak Ginger Alliance, s.r.o. www.gingerall.cz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FOP/Cocoon performance tips?
Hi all, I'm running quite complex XML XSL-FO PDF transformation generating book packages. One package consists of: - 2 full books (Student Guide, Instructor Guide) of approx 200 pages each - separate handouts in 3 booklets (each of 30-40 pages) All targets are generated from the same XML source. Average book contains 80-150 images. To generate the package takes about 10 minutes. I need to push this value down, as a client is not quite happy with it :| I'm looking for possible optimization in area of Cocoon/FOP config. (I know there can be also some 'resources' in xslt part of the job, but IMHO it would not bring too much at this point - I measured the time Xalan needs to transform xml to xsl-fo and it is just a fraction of time FOP needs to generate its output...) Environment: *Linux (Debian or Fedora) Cocoon (2.1.9) as part of Tomcat webapp; FOP 0.92beta with embed Xalan I hope there is many of you far more experienced with given set and you could give me some hints :) (FOP/Java environment, cocoon cache - what is worth to cache?) Thanks in advance Martin -- Martin Zak project manager, developer Ginger Alliance, s.r.o. Otakarova 15 140 00 Prague Czech Republic Office: tel +420 241 741 406 : fax +420 241 740 398 YM ID : zakmart Email : [EMAIL PROTECTED] http://www.gingerall.com http://www.ga-mme.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP/Cocoon performance tips?
hi Christian, thanks for useful tip - it's nice overview. I'll focus on the part re image formats now, which surprised me a lot - I didn't expect so big differences between formats in processing! Anyway it may be worth to post this presentation somewhere in FOP resources/links section... Cheers Martin Christian Geisert wrote: Martin Zak schrieb: Hi all, I'm running quite complex XML XSL-FO PDF transformation generating book packages. One package consists of: - 2 full books (Student Guide, Instructor Guide) of approx 200 pages each - separate handouts in 3 booklets (each of 30-40 pages) All targets are generated from the same XML source. Average book contains 80-150 images. Which image format are you using? If you aren't using jpegs you might try it this format because those will be directly embedded in (PDF and PS) documents which is faster than decoding the images. Do you know Jeremias' presentation Apache FOP: Optimizing speed and memory consumption[1]? Seems we have no link on the FOP website ... -- Martin Zak project manager, developer Ginger Alliance, s.r.o. Otakarova 15 140 00 Prague Czech Republic Office: tel +420 241 741 406 : fax +420 241 740 398 YM ID : zakmart Email : [EMAIL PROTECTED] http://www.gingerall.com http://www.ga-mme.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Extra space between following tables
Hi all, I'm rendering several simple tables one by one and experiencing the extra space between them. This space has no (IMHO) any reason, as tables has no space before/after or margin defined. I attached the simple example - two tables with one row and one cell, border defined on the table element to see the table block. When tables are placed as direct children of fo:flow, the output is correct - no space between. When I enclose these two tables to single fo:block, suddenly there is extra space rendered. I would appreciate any help... Cheers Martin === FOP version: 0.92beta Attachments: - tables.fo (source to render table_bug_wrong.pdf) - tables_wrong.pdf (tables with extra space between) - tables_correct.pdf (correct output after removing the enclosing fo:block) === ?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 margin-right=0.5in margin-left=0.5in margin-bottom=0.5in margin-top=0.5in page-width=8.5in page-height=11in master-name=chapter-page fo:region-body margin-left=0.5in margin-right=0.5in margin-top=0.5in margin-bottom=0.5in/ /fo:simple-page-master fo:page-sequence-master master-name=sequence-chapter fo:repeatable-page-master-alternatives fo:conditional-page-master-reference master-reference=chapter-page/ /fo:repeatable-page-master-alternatives /fo:page-sequence-master /fo:layout-master-set fo:page-sequence format=1 master-reference=sequence-chapter fo:flow font-family=Times font-size=12pt flow-name=xsl-region-body fo:block!-- remove this element to get correct output -- fo:table table-layout=fixed width=100% border=0.2pt solid green border-collapse=separate fo:table-column column-width=proportional-column-width(1)/ fo:table-body fo:table-row fo:table-cell fo:blockTable 1 Cell/fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table fo:table table-layout=fixed width=100% border=0.2pt solid green border-collapse=separate fo:table-column column-width=proportional-column-width(1)/ fo:table-body fo:table-row fo:table-cell fo:blockTable 2 Cell/fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:block!-- remove this element to get correct output -- /fo:flow /fo:page-sequence /fo:root tables_correct.pdf Description: Adobe PDF document tables_wrong.pdf Description: Adobe PDF document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
wrong width of region-body in sequence with first page different
Hi all, I have a sequence of pages for a book chapter with first page different. First page (it's always odd page) uses the end-region to show the short chapter TOC thus the region-body is narrowed (by the width of region-end). Following pages are alternatively even/odd pages with normal region-body (full width). When I render the sequence, first page looks ok (narrow body and toc on the right side). Unfortunately all other pages have _also_ narrowed region-body. In fact even/odd pages from sequence are used (as there is no region-end rendered), but the region-body of these pages gets the wrong width (which is the same as on first page). When I manually place the page-break to text flow, the following pages (after the break) are rendered OK (in full width)! I think I didn't miss anything and it seems to me as the FOP bug. Anyway I would like to ask the List prior posting a report... Any help welcomed :) Cheers Martin === FOP version: 0.92beta Attachments: - sequence_bug.fo (source to render sequence_bug_wrong.pdf) - sequence_bug_wrong.pdf (wrong region-body on second and following pages) - sequence_bug_correct.pdf (correct sequence after adding the page-break to text flow) Note: -the .fo snippet is simplified and works only with page sequence as [first/all others]. There are no even/odd pages. - the red border shows the topmost fo:block to highlight the region-body width. === ?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 margin-right=0.5in margin-left=0.5in margin-bottom=0.5in margin-top=0in page-width=8.5in page-height=11in master-name=chapter-page-first fo:region-body margin-left=0.5in margin-right=3in margin-top=1.5in margin-bottom=0.5in/ fo:region-end extent=2.75in region-name=chapter-TOC/ /fo:simple-page-master fo:simple-page-master margin-right=0.5in margin-left=0.5in margin-bottom=0.5in margin-top=0.5in page-width=8.5in page-height=11in master-name=chapter-page fo:region-body margin-left=0.5in margin-right=0.5in margin-top=0.5in margin-bottom=0.5in/ /fo:simple-page-master fo:page-sequence-master master-name=sequence-chapter fo:repeatable-page-master-alternatives fo:conditional-page-master-reference page-position=first master-reference=chapter-page-first/ fo:conditional-page-master-reference master-reference=chapter-page/ /fo:repeatable-page-master-alternatives /fo:page-sequence-master /fo:layout-master-set fo:page-sequence format=1 master-reference=sequence-chapter fo:static-content flow-name=chapter-TOC fo:block border-left=0.2pt solid #99 padding=0pt 0pt 20pt 10pt fo:block padding-top=1.5in + 10pt padding-bottom=10pt font-size=14ptIN THIS CHAPTER/fo:block fo:blockTopic 1/fo:block fo:blockTopic 2/fo:block fo:blockTopic 3/fo:block fo:blockTopic 4/fo:block /fo:block /fo:static-content fo:flow font-family=Times font-size=12pt margin-left=0in flow-name=xsl-region-body fo:block width=100% border=1pt solid red fo:block space-before=0mm font-family=Helvetica font-size=24pt font-weight=bold text-align=end color=#99 margin-left=0in1/fo:block fo:block space-before=5mm space-after=0.75in font-family=Times font-size=24pt font-weight=normal text-align=end color=black margin-left=0inIntroduction/fo:block fo:block space-before=15pt font-size=16pt font-weight=boldTopic 1/fo:block fo:blockLorem ipsum dolor sit amet, consectetuer adipiscing elit. Nulla sollicitudin ligula et leo. Duis dictum tempor nunc. Aliquam eros enim, fringilla ultrices, venenatis vel, egestas id, arcu. Nam non neque. Nunc vitae mauris. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Nulla sollicitudin ligula et leo. Duis dictum tempor nunc. Aliquam eros enim, fringilla ultrices, venenatis vel, egestas id, arcu. Nam non neque. Nunc vitae mauris. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Nulla sollicitudin ligula et leo. Duis dictum tempor nunc. Aliquam eros enim, fringilla ultrices, venenatis vel, egestas id, arcu. Nam non neque. Nunc vitae mauris. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Nulla sollicitudin ligula et leo. Duis dictum tempor nunc. Aliquam eros enim, fringilla ultrices, venenatis vel, egestas id, arcu. Nam non neque. Nunc vitae mauris. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Nulla sollicitudin ligula et leo. Duis dictum tempor nunc. Aliquam eros enim, fringilla ultrices, venenatis vel, egestas id, arcu. Nam non neque. Nunc vitae mauris./fo:block fo:block space-before=15pt font-size=16pt font-weight=boldTopic 2/fo:block fo:blockLorem ipsum dolor sit amet, consectetuer adipiscing elit. Nulla sollicitudin ligula et leo. Duis dictum tempor nunc. Aliquam eros enim, fringilla ultrices, venenatis vel, egestas id, arcu. Nam non neque. Nunc vitae mauris. Lorem
