RE: 0.20.5 release
Hi, Sorry to drop in... Just ignore me if you don't see any relevance. In any case, don't bother answering me. Considering that tables are currently the only mean to control pagination, all my documents have a tendency to include lots of tables (and they all start with a TOC). I believe I'm not alone. I would say that any improvement in the memory usage associated with tables, IMHO, is kind of critical. BTW, there are currently 8 proposed patches in Bugzilla. Most of them look to me quite simple and inoquous, and 4 of them are marked as Enhamcements for version 0.20.5 (there is also an older one for version 0.20.3). It would be nice if one of you guys could take a look at those patches and consider them before issuing the final 0.20.5 release. Congratulations to you all on an excellent job, you are doing, Ricardo Amador -Original Message- From: Christian Geisert [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 6:16 PM To: [EMAIL PROTECTED] Subject: 0.20.5 release Ok, RC3a seems to be rather stable and the changes since then look non-critical to me. What about doing the release now (read: next days) (and maybe 0.20.5a later if we get more hyphenation patterns back) Or should we make the changes proposed by Jörg (improved memory usage with tables - see http://marc.theaimsgroup.com/?l=fop-devm=105399053227758 ) which would require another release candidate. Comments please! Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Named Destinations
Hi Stefan,
I agree with you, it is safer and nicer that way.
I'm currently trying to install WinCVS, hoping to be able to produce
better patches (this patch stuff is new to me). I'll post the updated
patches as soon as possible.
Best Regards,
Ricardo
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 18, 2003 11:45 AM
To: Ricardo Amador
Cc: [EMAIL PROTECTED]
Subject: Re: Named Destinations
Hi Ricardo,
your additions seem right to me. Yet, I would recommend not to replace
the #dest=-syntax by the the #nameddest-syntax but to add simply
another option. In other words there would be the following options to
specify named
destinations:
1. .pdf#page=
2. .pdf#dest=
3. .pdf#nameddest=
4. .pdf#
The syntax used inside FOP to describe named destination must not
necessarily support only what Adobe suggests.
--Stefan
Hi all,
I'm really glad to see that in 0.20.5 it will be possible to create
named destinations in PDF. I have some small sugestions about this
functionality.
I'm using Acrobat Reader 5.1 and I was surprised to find out that the
url syntax '.pdf#dest=NamedDest' wasn't working for me. I've looked
deeper into
http://www.adobe.com/products/acrobat/pdfs/c01acrotip.pdf#page=4 and I
found a difference between the table (.pdf#dest=NamedDest) and the
examples (.pdf#namedest=NamedDest). Helas the syntax
'.pdf#namedest=NamedDest' also didn't work. Finally I've tried the
syntax '.pdf#nameddest=NamedDest' and it worked. I've also tested
the syntax '.pdf#NamedDest' and it also works fine. After some
googling I found http://www.adobe.com/support/techdocs/a17e.htm and it
looks like that the later form is really the one supported. If you
believe it to be safe, the changes required to contemplate the working
forms in pdf/PDFDocument.java would be:
Change PDF urls with named destinations
Diff for src/org/apache/fop/pdf/PDFDocument.java (rev 1.30.2.8)
1096c1096
} else if ((index = destination.indexOf(.pdf#dest=))
0) {
---
} else if ((index =
destination.indexOf(.pdf#nameddest=)) 0) {
1098c1098,1106
String dest = destination.substring(index + 10);
---
String dest = destination.substring(index + 15);
PDFFileSpec fileSpec = new
PDFFileSpec(++this.objectcount, file);
this.objects.add(fileSpec);
action = new PDFGoToRemote(++this.objectcount,
fileSpec, dest);
this.objects.add(action);
link.setAction(action);
} else if ((index = destination.indexOf(.pdf#)) 0)
{
String file = destination.substring(0, index + 4);
String dest = destination.substring(index + 5);
In my use of named destinations, I generate named destinations for
every bookmark I have in my documents. The fact that the extension
element fox:destination is only processed when used as a root
element forces me to make and additional pass on my xml document just
to generate the named destinations. If fox:destination was also
processed whent it is used as a child of a fox:outline, I could avoid
that additional pass. One way to achieve this, would be to add/change
the following in extensions/Outline.java and
render/pdf/PDFRenderer.java:
Allow fox:destination as child of fox:outline
Diff for src/org/apache/fop/extensions/Outline.java (maint rev
1.4.2.5) 63a64
private ArrayList _destinations = new ArrayList();
119a121,122
} else if (obj instanceof Destination) {
_destinations.add(obj);
142a146,149
}
public ArrayList getDestinations() {
return _destinations;
Diff for src/org/apache/fop/render/pdf/PDFRenderer.java (maint rev
1.91.2.15)
986,987c986
Destination d = (Destination)ext;
pdfDoc.addDestination(d.getDestinationName(),
d.getInternalDestination());
---
renderDestination((Destination) ext);
1021a1021,1030
// handle sub destinations
List vd = outline.getDestinations();
for (int i = 0; i vd.size(); i++) {
renderDestination((Destination) vd.get(i));
}
}
private void renderDestination(Destination d) {
pdfDoc.addDestination(d.getDestinationName(),
d.getInternalDestination());
BTW, shouldn't the method getName in extensions/Outline.java return
fox:outline instead of fop:outline? The constructor warning
messages use fox:outline.
This is probably not the best way to provide this kind of patches. If
you need anything else, feel free to ask, I'll do my best. I try to
follow the digest of this list, but it might be better to email me
directly also. In the last few days I've also added some problems to
Bugzilla. This is the first time I use Bugzilla and I've tried not to
waste your time and be as effective
[PATCH] Named Destinations (was RE: Named Destinations)
Here are the updated patches to:
- Add .pdf#nameddest= and .pdf# as alternative syntax forms of PDF
urls with named destinations (according to Stefan recommendation):
pdfurl.diff
- Add processing of fox:destination as child of fox:outline (no
changes, but as an attachement there are no wrapped lines):
outlndest.diff
-Original Message-
From: Ricardo Amador [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 18, 2003 7:41 PM
To: '[EMAIL PROTECTED]'
Cc: '[EMAIL PROTECTED]'
Subject: RE: Named Destinations
Hi Stefan,
I agree with you, it is safer and nicer that way.
I'm currently trying to install WinCVS, hoping to be able to produce
better patches (this patch stuff is new to me). I'll post the updated
patches as soon as possible.
Best Regards,
Ricardo
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 18, 2003 11:45 AM
To: Ricardo Amador
Cc: [EMAIL PROTECTED]
Subject: Re: Named Destinations
Hi Ricardo,
your additions seem right to me. Yet, I would recommend not to replace
the #dest=-syntax by the the #nameddest-syntax but to add simply
another option. In other words there would be the following options to
specify named
destinations:
1. .pdf#page=
2. .pdf#dest=
3. .pdf#nameddest=
4. .pdf#
The syntax used inside FOP to describe named destination must not
necessarily support only what Adobe suggests.
--Stefan
Hi all,
I'm really glad to see that in 0.20.5 it will be possible to create
named destinations in PDF. I have some small sugestions about this
functionality.
I'm using Acrobat Reader 5.1 and I was surprised to find out that the
url syntax '.pdf#dest=NamedDest' wasn't working for me. I've looked
deeper into
http://www.adobe.com/products/acrobat/pdfs/c01acrotip.pdf#page=4 and I
found a difference between the table (.pdf#dest=NamedDest) and the
examples (.pdf#namedest=NamedDest). Helas the syntax
'.pdf#namedest=NamedDest' also didn't work. Finally I've tried the
syntax '.pdf#nameddest=NamedDest' and it worked. I've also tested
the syntax '.pdf#NamedDest' and it also works fine. After some
googling I found http://www.adobe.com/support/techdocs/a17e.htm and it
looks like that the later form is really the one supported. If you
believe it to be safe, the changes required to contemplate the working
forms in pdf/PDFDocument.java would be:
Change PDF urls with named destinations
Diff for src/org/apache/fop/pdf/PDFDocument.java (rev 1.30.2.8)
1096c1096
} else if ((index = destination.indexOf(.pdf#dest=))
0) {
---
} else if ((index =
destination.indexOf(.pdf#nameddest=)) 0) {
1098c1098,1106
String dest = destination.substring(index + 10);
---
String dest = destination.substring(index + 15);
PDFFileSpec fileSpec = new
PDFFileSpec(++this.objectcount, file);
this.objects.add(fileSpec);
action = new PDFGoToRemote(++this.objectcount,
fileSpec, dest);
this.objects.add(action);
link.setAction(action);
} else if ((index = destination.indexOf(.pdf#)) 0)
{
String file = destination.substring(0, index + 4);
String dest = destination.substring(index + 5);
In my use of named destinations, I generate named destinations for
every bookmark I have in my documents. The fact that the extension
element fox:destination is only processed when used as a root
element forces me to make and additional pass on my xml document just
to generate the named destinations. If fox:destination was also
processed whent it is used as a child of a fox:outline, I could avoid
that additional pass. One way to achieve this, would be to add/change
the following in extensions/Outline.java and
render/pdf/PDFRenderer.java:
Allow fox:destination as child of fox:outline
Diff for src/org/apache/fop/extensions/Outline.java (maint rev
1.4.2.5) 63a64
private ArrayList _destinations = new ArrayList();
119a121,122
} else if (obj instanceof Destination) {
_destinations.add(obj);
142a146,149
}
public ArrayList getDestinations() {
return _destinations;
Diff for src/org/apache/fop/render/pdf/PDFRenderer.java (maint rev
1.91.2.15)
986,987c986
Destination d = (Destination)ext;
pdfDoc.addDestination(d.getDestinationName(),
d.getInternalDestination());
---
renderDestination((Destination) ext);
1021a1021,1030
// handle sub destinations
List vd = outline.getDestinations();
for (int i = 0; i vd.size(); i++) {
renderDestination((Destination) vd.get(i));
}
}
private void renderDestination(Destination d) {
pdfDoc.addDestination(d.getDestinationName(),
d.getInternalDestination());
BTW, shouldn't the method getName
