You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Laurent Caillette <La...@ullink.com> on 2009/08/19 11:38:37 UTC
Referencing multiple pages for index entries
Hi all,
First, I'd like to thank all FOP developers for creating such a great tool that tackles really, really hard problems. I'm developing an OSS tool for generating PDF (and other formats) from a wiki-like syntax and it uses FOP instensively.
Now I met some people that could be interested by Novelang (the OSS tool of mine) but they need index entries. XSL 1.1 specification supports this, but in the short term FOP doesn't seem to be implementing it.
FO markers are great for single pages, but they come short when referencing several pages, as we don't want duplicate entries like "3, 3, 5, 6, 6, 7" ("3, 5-7" wanted instead).
A solution for a reasonable amount of work seems to be a FOP extension acting like a marker but supporting multiple entries, calculating page ranges and removing duplicates.
I've looked at extension samples (MathML, Barcode4J). They all work as rectangular graphical areas. I could find none working as a text flow.
- Is it possible to implement an extension generating text flow?
- If yes, where can I find such an example?
- If no, any other idea?
Regards,
Laurent Caillette
http://novelang.sourceforge.net
__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 4347 (20090819) __________
Le message a ?t? v?rifi? par ESET NOD32 Antivirus.
http://www.eset.com
Re: AW: Referencing multiple pages for index entries
Posted by Andreas Delmelle <an...@telenet.be>.
On 20 Aug 2009, at 12:10, Georg Datterl wrote:
Hi Georg, Laurent,
>
>> Yesterday evening I had a look at the FOP code with your other
>> proposal about Knuth Sequence in mind. Well, that's too hard
>> for me yet and I'll take the "easy" (hum) way for the moment.
>
> I don't understand the theory behind it either but if I'm not
> mistaken, you can look at the sequence of KnuthElements as just a
> chain of small text areas separated by spaces (=penalties) and break-
> possibilities. But before I make a complete fool out of myself, I
> better leave that topics to the experts.
Basically not bad as an interpretation, although KnuthElements are
generated that represent border, padding etc. rather than merely 'text
fragments'. And OTOH, penalties actually do not correspond to spaces.
Penalties represent break-possibilities (or -impossibilities if
penalty=INFINITE). Spaces, in the most common case, correspond to
KnuthGlue objects, which are a break-possibility only if they are
preceded by a KnuthBox. In many cases, FOP generates a sequence of
penalty-box-glue for a space (to avoid a break before, or to hint at
what happens if there is a break before --i.e. how much width should
be added to the line when choosing that possibility as an effective
break)
Regards
Andreas
Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandreas@jabber.org
skype: adlm0608
---
AW: Referencing multiple pages for index entries
Posted by Georg Datterl <ge...@geneon.de>.
Hi Laurent,
> Those ids are good news. Now I need to experiment a bit,
> then things wil get clearer I think.
Yes, the id attribute is the most usefull attribute when working with the area tree. :-)
> Intermediate Format looks like a good choice for such a
> hack but I've downloaded a FOP snapshot (805900) and
> the ``IntermediateFormatTestSuite`` takes forever (running
> Ant default target under Windows XP with `Ant-1.7.0`). Hope
> this will be fixed soon!
Well, you don't need that too often. Only when generating a build.
> Yesterday evening I had a look at the FOP code with your other
> proposal about Knuth Sequence in mind. Well, that's too hard
> for me yet and I'll take the "easy" (hum) way for the moment.
I don't understand the theory behind it either but if I'm not mistaken, you can look at the sequence of KnuthElements as just a chain of small text areas separated by spaces (=penalties) and break-possibilities. But before I make a complete fool out of myself, I better leave that topics to the experts.
Regards,
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
-----Ursprüngliche Nachricht-----
Von: Laurent Caillette [mailto:Laurent.Caillette@ullink.com]
Gesendet: Donnerstag, 20. August 2009 11:46
An: fop-dev@xmlgraphics.apache.org
Betreff: RE: Referencing multiple pages for index entries
Thanks Georg,
Those ids are good news. Now I need to experiment a bit, then things wil get clearer I think.
Intermediate Format looks like a good choice for such a hack but I've downloaded a FOP snapshot (805900) and the ``IntermediateFormatTestSuite`` takes forever (running Ant default target under Windows XP with `Ant-1.7.0`). Hope this will be fixed soon!
Yesterday evening I had a look at the FOP code with your other proposal about Knuth Sequence in mind. Well, that's too hard for me yet and I'll take the "easy" (hum) way for the moment.
Regards,
c.
-----Message d'origine-----
De : Georg Datterl [mailto:georg.datterl@geneon.de] Envoyé : jeudi 20 août 2009 10:11 À : fop-dev@xmlgraphics.apache.org Objet : AW: Referencing multiple pages for index entries
Hi Laurent,
The index page is indeed the very last page, but since I still have the fo file, I can add further indizes and cover pages later. I just don't have them at the moment and I don't need them for the correct page numbers of the index, so I can look for the last page. You might as well use a table to display your entries and find the table by id instead of the page. Actually, I wouldn't need to find the page at all, since I search for the entries directly in my xpath statement, but stripping the unneeded nodes reduces the time needed to find all the page numbers from 2 hours to 2 minutes with even medium sized documents!
prod-id is the area tree name for the id attribute of fo-elements. Each page-number-citation element gets a (of course) unique id and I keep a map of which elements belong to which entries. Then I get the ids and the actual page numbers from the area tree and can strip page-number-citation elements from the fo file. Using id/prod-id is robust, since it can't be confused by user content and fop requires ids to be unique anyway.
Mit freundlichen Grüßen
Georg Datterl
__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 4350 (20090820) __________
Le message a été vérifié par ESET NOD32 Antivirus.
http://www.eset.com
RE: Referencing multiple pages for index entries
Posted by Laurent Caillette <La...@ullink.com>.
Thanks Georg,
Those ids are good news. Now I need to experiment a bit, then things wil get clearer I think.
Intermediate Format looks like a good choice for such a hack but I've downloaded a FOP snapshot (805900) and the ``IntermediateFormatTestSuite`` takes forever (running Ant default target under Windows XP with `Ant-1.7.0`). Hope this will be fixed soon!
Yesterday evening I had a look at the FOP code with your other proposal about Knuth Sequence in mind. Well, that's too hard for me yet and I'll take the "easy" (hum) way for the moment.
Regards,
c.
-----Message d'origine-----
De : Georg Datterl [mailto:georg.datterl@geneon.de]
Envoyé : jeudi 20 août 2009 10:11
À : fop-dev@xmlgraphics.apache.org
Objet : AW: Referencing multiple pages for index entries
Hi Laurent,
The index page is indeed the very last page, but since I still have the fo file, I can add further indizes and cover pages later. I just don't have them at the moment and I don't need them for the correct page numbers of the index, so I can look for the last page. You might as well use a table to display your entries and find the table by id instead of the page. Actually, I wouldn't need to find the page at all, since I search for the entries directly in my xpath statement, but stripping the unneeded nodes reduces the time needed to find all the page numbers from 2 hours to 2 minutes with even medium sized documents!
prod-id is the area tree name for the id attribute of fo-elements. Each page-number-citation element gets a (of course) unique id and I keep a map of which elements belong to which entries. Then I get the ids and the actual page numbers from the area tree and can strip page-number-citation elements from the fo file. Using id/prod-id is robust, since it can't be confused by user content and fop requires ids to be unique anyway.
Mit freundlichen Grüßen
Georg Datterl
__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 4350 (20090820) __________
Le message a été vérifié par ESET NOD32 Antivirus.
http://www.eset.com
AW: Referencing multiple pages for index entries
Posted by Georg Datterl <ge...@geneon.de>.
Hi Laurent,
The index page is indeed the very last page, but since I still have the fo file, I can add further indizes and cover pages later. I just don't have them at the moment and I don't need them for the correct page numbers of the index, so I can look for the last page. You might as well use a table to display your entries and find the table by id instead of the page. Actually, I wouldn't need to find the page at all, since I search for the entries directly in my xpath statement, but stripping the unneeded nodes reduces the time needed to find all the page numbers from 2 hours to 2 minutes with even medium sized documents!
prod-id is the area tree name for the id attribute of fo-elements. Each page-number-citation element gets a (of course) unique id and I keep a map of which elements belong to which entries. Then I get the ids and the actual page numbers from the area tree and can strip page-number-citation elements from the fo file. Using id/prod-id is robust, since it can't be confused by user content and fop requires ids to be unique anyway.
Mit freundlichen Grüßen
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
-----Ursprüngliche Nachricht-----
Von: Laurent Caillette [mailto:Laurent.Caillette@ullink.com]
Gesendet: Mittwoch, 19. August 2009 18:15
An: fop-dev@xmlgraphics.apache.org
Betreff: RE: Referencing multiple pages for index entries
Thanks Georg.
As far as I understand your code, the page containing index entries is the very last child of the DOM tree and the ``prod-id`` attribute contains some kind of unique identifier corresponding to a known page. Am I right?
I'd like to allow other page sequences following index entries, and those may span on several pages, so last DOM child may not be the right one to search into. That's why I'm asking for a robust mechanism to surround index keys and page numbers.
For sure I could use magic text like "XxxxSTARTxxxX" and "XxxxENDxxxX" but this could be fooled by any user content. Looking at the IF draft on FOP wiki I see there is a "page-name" attribute for the page. Setting such a an attribute value (not necessarily this one) from FO would save me, then.
c.
-----Message d'origine-----
De : Georg Datterl [mailto:georg.datterl@geneon.de] Envoyé : mercredi 19 août 2009 15:20 À : fop-dev@xmlgraphics.apache.org Objet : AW: Referencing multiple pages for index entries
Hi Laurent,
> In real world use cases, it's acceptable to support index entries only
> at the end of the numbering sequence or in another numbering sequence,
> so let's do post-processing. There are plenty of issues to solve but
> they are mostly related to `I/Os` and XSL and Novelang design so I
> won't discuss them in this list.
I'm just thinking: If we are restricted to an index in a separate page-sequence after the actual entries, wouldn't it be possible DURING the layout (when creating the KnuthSequence?) to look forward (or back) and modify the entries (which already should know their page number), and then layout once?
> One question left, however. I wonder how to hint FO document for
> generating Area Tree or Intermediate Format that I could reparse
> easily, for locating pages containing index entries, and extracting
> index keys and lists of page numbers.
__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 4348 (20090819) __________
Le message a été vérifié par ESET NOD32 Antivirus.
http://www.eset.com
RE: Referencing multiple pages for index entries
Posted by Laurent Caillette <La...@ullink.com>.
Thanks Georg.
As far as I understand your code, the page containing index entries is the very last child of the DOM tree and the ``prod-id`` attribute contains some kind of unique identifier corresponding to a known page. Am I right?
I'd like to allow other page sequences following index entries, and those may span on several pages, so last DOM child may not be the right one to search into. That's why I'm asking for a robust mechanism to surround index keys and page numbers.
For sure I could use magic text like "XxxxSTARTxxxX" and "XxxxENDxxxX" but this could be fooled by any user content. Looking at the IF draft on FOP wiki I see there is a "page-name" attribute for the page. Setting such a an attribute value (not necessarily this one) from FO would save me, then.
c.
-----Message d'origine-----
De : Georg Datterl [mailto:georg.datterl@geneon.de]
Envoyé : mercredi 19 août 2009 15:20
À : fop-dev@xmlgraphics.apache.org
Objet : AW: Referencing multiple pages for index entries
Hi Laurent,
> In real world use cases, it's acceptable to support index entries
> only at the end of the numbering sequence or in another numbering
> sequence, so let's do post-processing. There are plenty of issues
> to solve but they are mostly related to `I/Os` and XSL and Novelang
> design so I won't discuss them in this list.
I'm just thinking: If we are restricted to an index in a separate page-sequence after the actual entries, wouldn't it be possible DURING the layout (when creating the KnuthSequence?) to look forward (or back) and modify the entries (which already should know their page number), and then layout once?
> One question left, however. I wonder how to hint FO document for
> generating Area Tree or Intermediate Format that I could reparse
> easily, for locating pages containing index entries, and extracting
> index keys and lists of page numbers.
__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 4348 (20090819) __________
Le message a été vérifié par ESET NOD32 Antivirus.
http://www.eset.com
AW: Referencing multiple pages for index entries
Posted by Georg Datterl <ge...@geneon.de>.
Hi Laurent,
> In real world use cases, it's acceptable to support index entries
> only at the end of the numbering sequence or in another numbering
> sequence, so let's do post-processing. There are plenty of issues
> to solve but they are mostly related to `I/Os` and XSL and Novelang
> design so I won't discuss them in this list.
I'm just thinking: If we are restricted to an index in a separate page-sequence after the actual entries, wouldn't it be possible DURING the layout (when creating the KnuthSequence?) to look forward (or back) and modify the entries (which already should know their page number), and then layout once?
> One question left, however. I wonder how to hint FO document for
> generating Area Tree or Intermediate Format that I could reparse
> easily, for locating pages containing index entries, and extracting
> index keys and lists of page numbers.
I don't know if that helps you, but I generate the area tree as a DOM Document and then read data from it. The blocks I'm interested in are marked with known ids.
private org.w3c.dom.Document multipass(StreamSource source) {
try {
FopFactory fopFactory = getFopFactory();
FOUserAgent foUserAgent = fopFactory.newFOUserAgent();
SAXTransformerFactory mpFactory = getMultipassFactory();
Transformer transformer = mpFactory.newTransformer();
TransformerHandler handler = mpFactory.newTransformerHandler();
DOMResult domResult = new DOMResult();
handler.setResult(domResult);
org.apache.fop.render.Renderer targetRenderer =
foUserAgent.getRendererFactory().createRenderer(
foUserAgent, MimeConstants.MIME_PDF);
XMLRenderer renderer = new XMLRenderer();
renderer.mimicRenderer(targetRenderer);
renderer.setContentHandler(handler);
renderer.setUserAgent(foUserAgent);
foUserAgent.setRendererOverride(renderer);
Fop fop = fopFactory.newFop(foUserAgent);
Result res = new SAXResult(fop.getDefaultHandler());
transformer.transform(source, res);
org.w3c.dom.Document doc = domResult.getNode();
// killing all but the last page from the document, because of performance reasons. IMPORTANT, trust me!!
while (!doc.getDocumentElement().getLastChild().equals(doc.getDocumentElement().getFirstChild())) {
doc.getDocumentElement().removeChild(doc.getDocumentElement().getFirstChild());
}
// read the data from the document, get the entries to kill (Strings in Set res are reference ids of pagenumber entries)
XPathFactory factory=XPathFactory.newInstance();
XPath xPath=factory.newXPath();
NodeList nl = (NodeList)xPath.evaluate("//block[@prod-id='"+pageKey+"']", doc, XPathConstants.NODESET);
if (nl.getLength()<=0) {
return res;
}
Node root = nl.item(0);
for (String key : references.keySet()) {
Set<String> uniques = new HashSet<String>();
Set<String> toCheck = references.get(key);
if (toCheck.size()>1) { // bei einem: immer unique, also egal.
for (String check : toCheck) {
String val = xPath.evaluate(".//text[@prod-id='"+check+"']/word/text()", root, XPathConstants.STRING).toString();
if (uniques.contains(val)) {
res.add(check);
}
else {
uniques.add(val);
}
}
}
}
// With this ids I iterate over my structure and remove elements with ids in the set. Which probably won't help you much.
} catch (TransformerException e) {
System.out.println(e.getMessage());
e.printStackTrace();
} catch (FOPException e) {
System.out.println(e.getMessage());
e.printStackTrace();
// } catch (IOException e) {
// System.out.println(e.getMessage());
// e.printStackTrace();
} catch (SAXException e) {
System.out.println(e.getMessage());
e.printStackTrace();
}
return null;
}
Mit freundlichen Grüßen
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
-----Ursprüngliche Nachricht-----
Von: Laurent Caillette [mailto:Laurent.Caillette@ullink.com]
Gesendet: Mittwoch, 19. August 2009 14:56
An: fop-dev@xmlgraphics.apache.org
Betreff: RE: Referencing multiple pages for index entries
Thanks Georg, the "Index and Pagenumbers" discussion is of great interest.
To sum up:
- By design, FOP doesn't re-layout after page number citations (as shown by Andreas D.). So a FOP extension won't solve my case if I want nicely-formatted index entries.
- Complete support of `XSL 1.1` indexes means supporting growing and shrinking entries. When not at the very end of the page sequence, this implies multi-pass layout.
- By design, FOP doesn't support multi-pass layout.
- But FOP allows post-processing through Area Tree Format or Intermediate Format.
In real world use cases, it's acceptable to support index entries only at the end of the numbering sequence or in another numbering sequence, so let's do post-processing. There are plenty of issues to solve but they are mostly related to `I/Os` and XSL and Novelang design so I won't discuss them in this list.
One question left, however. I wonder how to hint FO document for generating Area Tree or Intermediate Format that I could reparse easily, for locating pages containing index entries, and extracting index keys and lists of page numbers.
Thanks all,
c.
-----Message d'origine-----
De : Georg Datterl [mailto:georg.datterl@geneon.de] Envoyé : mercredi 19 août 2009 12:08 À : fop-dev@xmlgraphics.apache.org Objet : AW: Referencing multiple pages for index entries
Hi Laurent,
I had the same problem, except for the "5-7". I only had to remove multiple entries with identical page numbers. A search for buzzword index in the archives should unearth that thread ("Index and Pagenumbers").
__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 4347 (20090819) __________
Le message a été vérifié par ESET NOD32 Antivirus.
http://www.eset.com
RE: Referencing multiple pages for index entries
Posted by Laurent Caillette <La...@ullink.com>.
Thanks Georg, the "Index and Pagenumbers" discussion is of great interest.
To sum up:
- By design, FOP doesn't re-layout after page number citations (as shown by Andreas D.). So a FOP extension won't solve my case if I want nicely-formatted index entries.
- Complete support of `XSL 1.1` indexes means supporting growing and shrinking entries. When not at the very end of the page sequence, this implies multi-pass layout.
- By design, FOP doesn't support multi-pass layout.
- But FOP allows post-processing through Area Tree Format or Intermediate Format.
In real world use cases, it's acceptable to support index entries only at the end of the numbering sequence or in another numbering sequence, so let's do post-processing. There are plenty of issues to solve but they are mostly related to `I/Os` and XSL and Novelang design so I won't discuss them in this list.
One question left, however. I wonder how to hint FO document for generating Area Tree or Intermediate Format that I could reparse easily, for locating pages containing index entries, and extracting index keys and lists of page numbers.
Thanks all,
c.
-----Message d'origine-----
De : Georg Datterl [mailto:georg.datterl@geneon.de]
Envoyé : mercredi 19 août 2009 12:08
À : fop-dev@xmlgraphics.apache.org
Objet : AW: Referencing multiple pages for index entries
Hi Laurent,
I had the same problem, except for the "5-7". I only had to remove multiple entries with identical page numbers. A search for buzzword index in the archives should unearth that thread ("Index and Pagenumbers").
__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 4347 (20090819) __________
Le message a été vérifié par ESET NOD32 Antivirus.
http://www.eset.com
AW: Referencing multiple pages for index entries
Posted by Georg Datterl <ge...@geneon.de>.
Hi Laurent,
I had the same problem, except for the "5-7". I only had to remove multiple entries with identical page numbers. A search for buzzword index in the archives should unearth that thread ("Index and Pagenumbers").
Important parts:
------------ by Jeremias Maerki -------------
* XSL 1.1 contains support for building indices but that hasn't been implemented in FOP, yet.
------------ by Jeremias Maerki -------------
At the moment, the resolution of page-number-citations can happen in two places at the moment: 1. In PageNumberCitationLayoutManager where the page number is directly entered as a TextArea if the target page is already known. 2. In area.inline.UnresolvedPageNumber if the target page is only known at a later stage. In this case the page number is squeezed into some pre-reserved space. This avoids a two-pass layout approach that other implementations use but it has its limitations.
The problem for you: In case 2, the layout engine is no longer operating and you cannot adjust properly for larger amounts of text (multiple p-n-cs that are suddenly gone). However, since word indices are normally at the end of a document, this might be something you can avoid.
------------- by Andreas Delmelle ------------
I once started gathering some thoughts on the topic, but didn't get very far... See: http://wiki.apache.org/xmlgraphics-fop/FormattingObjectsForIndexing
By itself, the implementation of the 'index-key' property is not that difficult. It is its treatment further on during layout/rendering that will be a challenge.
If you're interested, I'll be glad to co-operate on this one.
-----------------------------------------------
My personal solution was actually: I generated the fo-file to area tree, read the page numbers, deleted entries from the original fo file and generated the resulting fo-file to pdf.
Regards,
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
-----Ursprüngliche Nachricht-----
Von: Laurent Caillette [mailto:Laurent.Caillette@ullink.com]
Gesendet: Mittwoch, 19. August 2009 11:39
An: fop-dev@xmlgraphics.apache.org
Betreff: Referencing multiple pages for index entries
Hi all,
First, I'd like to thank all FOP developers for creating such a great tool that tackles really, really hard problems. I'm developing an OSS tool for generating PDF (and other formats) from a wiki-like syntax and it uses FOP instensively.
Now I met some people that could be interested by Novelang (the OSS tool of mine) but they need index entries. XSL 1.1 specification supports this, but in the short term FOP doesn't seem to be implementing it.
FO markers are great for single pages, but they come short when referencing several pages, as we don't want duplicate entries like "3, 3, 5, 6, 6, 7" ("3, 5-7" wanted instead).
A solution for a reasonable amount of work seems to be a FOP extension acting like a marker but supporting multiple entries, calculating page ranges and removing duplicates.
I've looked at extension samples (MathML, Barcode4J). They all work as rectangular graphical areas. I could find none working as a text flow.
- Is it possible to implement an extension generating text flow?
- If yes, where can I find such an example?
- If no, any other idea?
Regards,
Laurent Caillette
http://novelang.sourceforge.net
__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 4347 (20090819) __________
Le message a ?t? v?rifi? par ESET NOD32 Antivirus.
http://www.eset.com