RE: PDF "meta" properties (was Re: basic-link)
> -Original Message- > From: Clay Leeds [mailto:[EMAIL PROTECTED] > > I was unaware that FOP has the ability to add Producer, Author and Title > properties to FOP. In fact, the web site still shows "FOP does not > currently support several desirable PDF features: document properties > (title, author, etc.), and watermarks.": > >http://xml.apache.org/fop/output.html#pdf > Maestro, Hold yer horses here... I had to do a bit of browsing around in the code to find out that support for these is already implemented. Once I saw this, it was merely a question of calling the appropriate method(s) in the Driver. (In fact, the producer field was already being used. At first I added the other properties to the code myself, after reading a bit through the pdf spec & based upon what was already there... Only to find out later on that these were also added by dev... :) ) > If support for these have been added, I think it would be great to add > this info to the web site. If it's been added to 1.0Dev then, as Emily > Litella would say... "never mind". > Hmmm... I doubt the way it works right now deserves to be put on the site somewhere, but still it's probably nice for some users to know that these features are already available under the surface somewhere. Greetz, Andreas
Re: PDF "meta" properties (was Re: basic-link)
Clay Leeds wrote: I was unaware that FOP has the ability to add Producer, Author and Title properties It can be set via the PDF renderer API, at least for HEAD. Maybe the producer is hardcoded to "FOP" or something (look into the source for details). It's not accessible on the command line yet. J.Pietschmann
PDF "meta" properties (was Re: basic-link)
Andreas L. Delmelle wrote: Right you are! Same here... A little experience with iText, but since FOP supports encryption and the producer / author / title props, I have seen little use for iText. I was unaware that FOP has the ability to add Producer, Author and Title properties to FOP. In fact, the web site still shows "FOP does not currently support several desirable PDF features: document properties (title, author, etc.), and watermarks.": http://xml.apache.org/fop/output.html#pdf If support for these have been added, I think it would be great to add this info to the web site. If it's been added to 1.0Dev then, as Emily Litella would say... "never mind". :-P
Re: basic-link brocken (maintenance branch)
Hi guys, If the problem is that the link rectangles are now merged by default, I am the one that changed it. There was a bug: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9335 and I was doing a bunch of improvements to the positioning of the link rectangles. However, in this case, all I did was change the default merge behavior to yes. Is there something else broken? Regards, Karen Jeremias Maerki wrote: I fixed a bug there, but this obviously brought another. I'll have a look at it. On Wed, 13 Nov 2002 12:17:59 +0100 Christian Geisert wrote: Hi, I just discoverd that basic-link isn't working as expected in the maintenance branch (docs/example/fo/links.fo for example) It seems that mergelinks() is the problem so I'll change the default links.merge to no if there are no objections. (IIRC there has been some discussion about this but a quick search on the mailing list did not find anything) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: BASIC-LINK
Sergio wrote: and the render crashes... If I make different the name of the basic-link or the name of the block id, the pdf is well rendered. I have anothers .fo files with many more links that are well rendered, but this file no. Why ? Looks too bizarre, open a bug in bugzilla and attach full fo document illustrating the problem. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: basic-link brocken (maintenance branch)
I fixed a bug there, but this obviously brought another. I'll have a look at it. On Wed, 13 Nov 2002 12:17:59 +0100 Christian Geisert wrote: > Hi, > > I just discoverd that basic-link isn't working as expected > in the maintenance branch (docs/example/fo/links.fo for example) > > It seems that mergelinks() is the problem so I'll change > the default links.merge to no if there are no objections. > (IIRC there has been some discussion about this but a quick > search on the mailing list did not find anything) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: basic-link internal-destination>
Hello, Suhail Rashid
the id is unique . Actaully in my whole document only have one basic-link
and only one id.
Do you have any idea or do u done before about internal-destination where
the in one page and in
another page?
hope you can help me.
Thank you.
lpkhoo
"Suhail
Rashid" To: <[EMAIL PROTECTED]>
Subject: RE: basic-link
internal-destination>
11/26/01 05:05
PM
Please respond
to fop-dev
the id has to be unique..
possibly ur assigning the same id at
more than one location in your document..
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 26, 2001 12:15 PM
To: [EMAIL PROTECTED]
Subject:
Hi,
I'm facing a problem in basic-link internal-destination. The problem is,
when my document in first page contain
internal-destination attribute then in second page contains the id
attribute (which refer to internal-destination).
When I run fop.0.20.1 the fop given me an error "The 'id' already exists
in
the document". If my document contain
internal-destination attribute and id attribute on same page then the
fop
can produce pdf file for me.
So, I hope that anyone can tell how to solved the problem.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: basic-link internal-destination>
the id has to be unique.. possibly ur assigning the same id at more than one location in your document.. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, November 26, 2001 12:15 PM To: [EMAIL PROTECTED] Subject: Hi, I'm facing a problem in basic-link internal-destination. The problem is, when my document in first page contain internal-destination attribute then in second page contains the id attribute (which refer to internal-destination). When I run fop.0.20.1 the fop given me an error "The 'id' already exists in the document". If my document contain internal-destination attribute and id attribute on same page then the fop can produce pdf file for me. So, I hope that anyone can tell how to solved the problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Basic Link
L. has send the complete files as attached files to a comment to the bug on 08-08-2001. He/She also wrote that the variable and function names are subject to think about. Enrico > I applied the patch, which seemed to solve the problem, but I would like > someone to examine it and change a bit. > > 1. the idValidation vs. idUnvalidated names are very confusing > without comments that explain what's what. > > 2. the createID method needs better commenting. I'm not entirely sure > I correctly understand it, so I didn't do so. > > Thanks for the patch L. McKenzie (?), but please send patches to the list > so we won't miss them. We don't mind the full files if you don't have > access > to CVS, either, but we'll include them faster if you do: > diff -u MyJava.java.orig MyJava.java >> patchfile.diff > > Enrico, thanks for pointing this patch as it was languishing. > -Steve > > -Original Message- > From: Enrico Schnepel [mailto:[EMAIL PROTECTED]] > Sent: Thursday, August 30, 2001 4:34 PM > To: [EMAIL PROTECTED] > Subject: Re: Basic Link > > > Hello Keiron, > > I had the same problem a few weeks ago and the bug is in the buglist as > bug > 3007. > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3007 > > The bug was resolved by [EMAIL PROTECTED] but is not merged yet > I've attached the corresponding files which resolves the problem. > > Enrico > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Basic Link
I applied the patch, which seemed to solve the problem, but I would like someone to examine it and change a bit. 1. the idValidation vs. idUnvalidated names are very confusing without comments that explain what's what. 2. the createID method needs better commenting. I'm not entirely sure I correctly understand it, so I didn't do so. Thanks for the patch L. McKenzie (?), but please send patches to the list so we won't miss them. We don't mind the full files if you don't have access to CVS, either, but we'll include them faster if you do: diff -u MyJava.java.orig MyJava.java >> patchfile.diff Enrico, thanks for pointing this patch as it was languishing. -Steve -Original Message- From: Enrico Schnepel [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 30, 2001 4:34 PM To: [EMAIL PROTECTED] Subject: Re: Basic Link Hello Keiron, I had the same problem a few weeks ago and the bug is in the buglist as bug 3007. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3007 The bug was resolved by [EMAIL PROTECTED] but is not merged yet I've attached the corresponding files which resolves the problem. Enrico - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Basic Link
> Basic links that have a destination that will be on a following page are
> broken.
> The changes involving the stream renderer do not check to make sure that
> the links are resolved before rendering the page, or more correctly, the id
> references don't care about basic links.
Unfortunately that's not always correct, I've found an example against
your theory. The is on page 2, the referenced link is on page
1. Have a look at the attached .fo and .pdf-file (don't be confused, the
links are invisible).
MfG, Daniel
--
Daniel Knapp <[EMAIL PROTECTED]>
int a=1,b,c=2800,d,e,f[2801],g;main(){for(;b-c;)f[b++]=a/5;for(;d=0,
g=c*2;c-=14,printf("%.4d",e+d/a),e=d%a)for(b=c;d+=f[b]*a,f[b]=d%--g,d/=
g--,--b;d*=b);} berechnet Pi auf 800 Stellen genau. :-)
http://www.w3.org/1999/XSL/Format";>
test_block
H.-R. Vatterrott
(Universität Rostock)
test
Dies ist ein Bespiel für einen Programmtext:
Na, zufrieden
?
Re: Basic Link
> Basic links that have a destination that will be on a following page are
> broken.
> The changes involving the stream renderer do not check to make sure that
> the links are resolved before rendering the page, or more correctly, the id
> references don't care about basic links.
You have just found the reason for Bug #3354 which I've searched for
several hours. Thank you very much! That explains that when copying the
lines where the link is into an new file no error happens, because the
link and the destination are on the same page.
MfG, Daniel
--
Daniel Knapp <[EMAIL PROTECTED]>
int a=1,b,c=2800,d,e,f[2801],g;main(){for(;b-c;)f[b++]=a/5;for(;d=0,
g=c*2;c-=14,printf("%.4d",e+d/a),e=d%a)for(b=c;d+=f[b]*a,f[b]=d%--g,d/=
g--,--b;d*=b);} berechnet Pi auf 800 Stellen genau. :-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
