Re: Build environment for alt.design
At 12:20 PM 7/4/2003, you wrote: [Happy Independence Day, fellow Americans!] and I always like to remind fellow Americans that the British call this "Thanksgiving Day"... ' Best, -Ralph LaChance In theory, there is no difference between theory and practice, but in practice there is. (Jan L.A. van de Snepsheut (1953-1994), late of CalTech) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: A FOP Renderer based on Java Printing System and Grapics2D
At 07:31 AM 4/5/2003, you wrote: My renderer, based on the Java Printing System and Graphics2D: pure Java does a perfect job. I will send sources, classes, documentation on request to my e-mail address. JU hmm. Am I getting blind in my old age - I don't see an email address in your post; for that matter I don't even see a signature ;-) Have you considered folding your work into FOP ? ' Best, -Ralph LaChance In theory, there is no difference between theory and practice, but in practice there is. (Jan L.A. van de Snepsheut (1953-1994), late of CalTech) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTE] logo contest vote, round 1
At 09:33 AM 3/30/2003, you wrote:
If non committers may vote, here is my (revised) list of 3
30, 10, [21 and/or 22]
darn, meant to say 30 as modified by Scott Hofman
- the one with the feather moved inside the O of Fop -
its kinda hard to vote for something that isn't on the page of pix ;-)
' Best,
-Ralph LaChance
In theory, there is no difference between
theory and practice, but in practice there is.
(Jan L.A. van de Snepsheut (1953-1994), late of CalTech)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: [VOTE] logo contest vote, round 1
If non committers may vote, here is my (revised) list of 3 30, 10, [21 and/or 22] At 09:16 AM 3/30/2003, you wrote: Oleg, The #30 on the site is the same as #7, AFAICT. The one you want is attached to: http://marc.theaimsgroup.com/?l=fop-dev&m=104839511309330&w=2. The original email message was sent on 2003-3-23, and is from Scott Hofman, if that helps. I have attached it to this message for your convenience. My choices: #30 (i.e. the version that is attached -- if we use this one, I think both Tobias & Scott should be credited) #10 #2 Victor Mote > -Original Message- > From: Oleg Tkachenko [mailto:[EMAIL PROTECTED] > Sent: Sunday, March 30, 2003 3:05 AM > To: [EMAIL PROTECTED] > Subject: [VOTE] logo contest vote, round 1 > > > Hello! > > I have added #30 as somehow modified #7 and added one new penguin logo. > Now lets finally finish with this stuff. As Peter suggested lets > vote by 3 > favorite logos first. > > My list: > #30 > #2 > #21 > > PS. Here is the list for you convenience: > http://vote.sparklit.com/web_poll.spark/714566 > -- > Oleg Tkachenko > http://www.tkachenko.com/blog > Multiconn Technologies, Israel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] ' Best, -Ralph LaChance In theory, there is no difference between theory and practice, but in practice there is. (Jan L.A. van de Snepsheut (1953-1994), late of CalTech) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: logo contest
Hi, I can't recall if the first winnowing round was for 3 or 4 picks, and I never noticed whether non-committers were even eligible to vote. So anyway, here's my $0.02 For round I nominate: 7, 10, 21 and/or 22 13 (maybe w/out the dot - I also think of visine) Many congratulations to all the submitters. Who would have expected so many worthy entries! -ralph committed, but not a committer ;-) ' Best, -Ralph LaChance In theory, there is no difference between theory and practice, but in practice there is. (Jan L.A. van de Snepsheut (1953-1994), late of CalTech) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] FOP 0.20.5 Release Candidate 2 available
At 09:08 AM 2/18/2003, you wrote: the second Release Candidate for 0.20.5 is finally available at http://www.apache.org/dist/xml/fop for downloading and testing. (New download location - please use a mirror if possible) Cheers, and congratulations all around. This was a bumpy one (especially for the drivers, I think) ' Best, -Ralph LaChance In theory, there is no difference between theory and practice, but in practice there is. (Jan L.A. van de Snepsheut (1953-1994), late of CalTech) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [svgplan] Status and future?
At 10:44 AM 2/3/2003, you wrote: - in Main there is no need to do a System.exit, that makes it impossible to reuse the class as a utility Be careful - check the archives on this one; seems to me this System.Exit has been added and removed half a dozen times over the past two or three releases. I certainly don't recall what the issues were, I'm just warning you it might not be a straightforward as it seems ;-) ' Best, -Ralph LaChance In theory, there is no difference between theory and practice, but in practice there is. (Jan L.A. van de Snepsheut (1953-1994), late of CalTech) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: source for hz algorithm
At 12:51 AM 1/31/2003, you wrote:
I made an inquiry on URW's web site yesterday, and received a response
today. The short story is that what I had inferred from the postings on
other lists is correct: the patent to hz-program is now owned by Adobe, and
is probably the basis for their paragraph-level formatting in InDesign. So
to summarize:
I'm puzzled how they can own a patent on an algorithm stated years
ago and summarized in a european student's thesis. But then I don'w
know about these things ;-)
' Best,
-Ralph LaChance
In theory, there is no difference between
theory and practice, but in practice there is.
(Jan L.A. van de Snepsheut (1953-1994), late of CalTech)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: FOP logo
At 04:34 PM 1/13/03, you wrote:
Maybe. But IMHO the letters "FOP" should be easily readable and the whole
logo shouldn't be too overloaded with additional stuff.
Yes, but that still leaves quite a bit of room for font experimentation.
I cannot resist -
How many programmers does it take to change a logo ?|;^)
' Best,
-Ralph LaChance
In theory, there is no difference between
theory and practice, but in practice there is.
(Jan L.A. van de Snepsheut (1953-1994), late of CalTech)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Opinion poll: Additional utility jars
At 02:11 PM 12/1/02, you wrote: Extensions to the original proposal: - Modularize FOP a bit better: build separate jars for the core, CLI, AWTViewer and the servlet (and move the servlet from contrib to the main src tree) gee, last I checked, the AWTViewer is fewer than a dozen classes, and I'd guess it ~doesn't~ use a at most 2 or 3 dozen class files from the fully-loaded jar (i.e., classes for the PDF and other renderers.) Is it really worth factoring fop into separate jars that differ so little ? ' Best, -Ralph LaChance In theory, there is no difference between theory and practice, but in practice there is. (Someone wrote that, but I don't know who.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Still on for freeze deadline?
At 06:30 AM 11/27/02, you wrote:
I don't even know when Thanksgiving is .. asking Google .. ah
it's on the fourth Thursday in November (i.e. tomorrow).
Well you might ask.
It is different in Canada (one month earlier) and then there
are the wags who suggest that July 4th, the anniversary
of America's independence is called Thanksgiving day
in the UK ;-)
' Best,
-Ralph LaChance
In theory, there is no difference between
theory and practice, but in practice there is.
(Someone wrote that, but I don't know who.)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Style guide (update)
Oh,
but congratulations to all the contributors for taking this on and getting
somewhere with it
At 09:15 AM 11/20/02, you wrote:
Hi there
I've finally finished the first draft for our style guide. I hope it's a
good start and I got a good mix from the discussions together. Please
review, change and comment. There were a lot of suggestions especially
from Jörg. I've summarized most of them under "common sense" but feel
free to expand if you feel it's necessary.
http://codeconsult.ch/wiki/index.php/FopDevelopersStyleGuide
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
' Best,
-Ralph LaChance
In theory, there is no difference between
theory and practice, but in practice there is.
(Someone wrote that, but I don't know who.)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Style guide (update)
At 09:15 AM 11/20/02, you wrote:
Please
review, change and comment.
re TBD section
1. strongy encourage m_ for instance variables, if only to eliminate
having to qualify similarly named assignments like
this.variable = variable
2. suggest s_ for statics and allow ALL_CAPS (underscores tolerated for
this usage only)
for static final (ie literals)
3. Sadly I ~don't~ like the Sun style for brace placement, but I guess I
learned in the
Fortran and PL/1 era. Guess I'm in the minority on that point ;-)
if (blahBlah){
line ;
line
} else {
line ;
line ;
}
vs
if (blahBlah)
{
line ;
line ;
}
else
{
line ;
line ;
}
4. I prefer Petzold's convention of placing a space before the terminating
semicolon (or even colon) which I believe he did for readability in
books,
and which I do for readability by my senior, crt-weary, eyes.
' Best,
-Ralph
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: patch process
At 07:05 AM 11/18/02, you wrote: Oleg Tkachenko wrote: Christian Geisert wrote: http://cvs.apache.org/snapshots/xml-fop/ We should add this to the documentation... http://xml.apache.org/fop/download.html mentions it already. Doh .. well .. Ralph should really RTFM ;-) I did - about 2 years ago. "Senior moments" come more often that that these days ;-) -Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
patch process
Hi all, I've worked out (and will submit via bugzilla) both an explanation and a solution to the text measuring & layout problems that I reported recently in the awt and awt/print renderers. I believe it makes sense to add the changes to the maintenance branch (in the event that there is ever an 0.20.5 release); in turn, they will be useful to inform the awt and awt/print renderer in the redesign, so I'll separately submit them to there if necessary. It's been a while since I've sent in patches, and wanted to check whether the preferred course is to submit the full sources (it affects 3 source files), or only diffs. And, if diffs, should they be against current CVS or against the 0.20.4 release. btw: Seems to me that http://xml.apache.org/dist/fop/ used to contain daily (twice daily?) snapshots of the latest source-in-progress. Did that change? ' Best, -Ralph as of now, ~4 hours later, it hadn't appeared in my inbox.> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Common code in CVS branches
At 02:09 AM 11/6/02, you wrote: I just went looking in the archives for this discussion & thought I saw pieces of it, but could not find what I was looking for -- namely, what theories you guys had proposed / agreed upon. This is related to the font work that I have started, i.e. I assume that the problem is a difference between metrics reported/used by the awt Font and those reported from our parsed metrics files. If it is not too much trouble, do you mind recapping a brief summary of where the issue stands now? Thanks. Victor (and Oleg, Keiron) I agree this should get summarized (and documented.) Presently, I am trying to systematically reproduce it here -- it may take another day or two, since the new JRE versions appear to behave differently (and still wrongly, it appears). -- And, frankly, I'm totally confused by what I'm seeing today. ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Common code in CVS branches
Oleg, Your comment about progress on the awt viewer is good news - I'm looking forward to trying it out ! Some months ago, we exchanged some notes regarding a problem in java that leads to a discrepancy in glyph measuring and rendering between printing and on-screen viewing. Does your work by any chance avoid or resolve those problems ? (For that matter, does your awt viewer handle printing?) At 11:38 AM 11/4/02, you wrote: Keiron Liddle wrote: The major areas of neglect would have to be: - font handling - api classes - awt viewer Please, reserve last one for me, I'm almost finishing with it. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] ' Best, -Ralph LaChance In theory, there is no difference between theory and practice, but in practice there is. (Someone wrote that, but I don't know who.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: handling patches (how about "fop 2")
Oooh - an inspired idea.
At 06:24 AM 11/2/02, you wrote:
On Saturday 02 November 2002 10:35, Victor Mote wrote:
>. . .I would also recommend that, in the above case,
> we actually put the code into two different projects.
>. . .
+1, I like the idea.
How about moving the "new" code (HEAD) to a separate (xml-fop2) CVS project
to clarify things, and maybe name the new version "fop 2" instead of 1.0x?
Although the current version is 0.20.x, it *is* used in production at a
number of sites, so going directly to version 2.x for a mostly new codebase
makes sense IMHO.
-Bertrand
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
' Best,
-Ralph LaChance
In theory, there is no difference between
theory and practice, but in practice there is.
(Someone wrote that, but I don't know who.)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: fonts
At 02:31 AM 10/8/02, you wrote:
>Will we have enough information out of AWT to produce high-quality
> text? For example, you need accurate information for the placement of
> under/overlines and superscript stuff.
$.02:
Underlines are in the (newish) LineMetrics object available from a Font,
nothing I know of about overlines, sub/super script per se.
One piece of bad news is that presently the JDK has a problem producing
identical output to the screen vs a printer (I documented the problem here a
couple months ago viz-a-viz Windows, at least.) As I recall, the rasterizer
comes up with output glyphs that do not match the size predicted by
measuring text using the font-metrics.
Even worse is that it seems to fails differently between depending on major
version ~ 1.3 and 1.4 ~ (maybe even among sub versions.)
I recall wondering if fop could get better results in the awt if, at the
time it
creates its reference font metrics, it were to know the actual target
(ie printer vs screen vs pdf) graphics context. Then I wondered what this
had to do with pdf and went to sleep...
' Best,
-Ralph LaChance
In theory, there is no difference between
theory and practice, but in practice there is.
(Someone wrote that, but I don't know who.)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: [PDF Viewer] Utility request
At 06:01 AM 7/29/02, I wrote:
>Anyone volunteering to profile awt's memory usage ?
Dumb comment. Sorry - Keiron's got the right answer
' Best,
-Ralph LaChance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: [PDF Viewer] Utility request
yes. Anyone volunteering to profile awt's memory usage ? At 05:40 AM 7/29/02, Ramana wrote: > >Ralph, > Your idea of "Fixing the awt renderer" is the correct one. After a >deep thought, I too came to the conclusion that instead of writing a PDF >renderer, if we can tune up the AWT renderer, it will be great. The main >problem with AWT renderer now is the heavy memory it uses. We need to find >the source of memory drain and tune it. > We need to come up with the basic plan for this. Also, we have to >first look and summarize the current issues with AWT renderer and step >accordingly. > >Ramana. > > > >-Original Message- >From: Ralph LaChance [mailto:[EMAIL PROTECTED]] >Sent: Monday, July 29, 2002 3:06 PM >To: [EMAIL PROTECTED] >Subject: Re: [PDF Viewer] Utility request > > >I agree with Oleg's last sentencetotally - which I translate roughly to >"lets fix the >awt renderer" > >In fact, I'd add a 3rd (or 2 1/2) user - the one who wishes to go directly >from >xml to a printer via fop. > >My colleagues here and I have inserted several changes to tweak spacings, >borders, >and so on over the past two years, and several other contributors have >refined the awt renderer over even more. > >Recently, I got stumped by a problem in that java's font engine rasterizes >glyphs >differently depending on whether the target was the on-screen graphics >context >or a printer context. (see archives) - anyone who could help unsnarl that >mess >would be making a noteworthy contribution. > >At 07:59 AM 7/28/02, you wrote: > >Matthew L. Avizinis wrote: > > It might also be helpful to recognize that as FOP becomes more popular >there > >>are distinctly _two_ groups of "users" emerging. The first group has been > >>using FOP from the beginning and those are the Java developers who use FOP > >>to create some other end product. Recently I've noticed that there are >more > >>people attempting to use FOP who are simply people who want to use FOP as >an > >>end product (more of an FO viewer) and want it to fulfill the role of a > >>product like X-Smiles (which unfortunately still falls far short of its >goal > >>of being a good FO viewer). > > > >I believe AWT previewer someday in the future will become some kind of FO > >IDE and afaik even nowadays somebody in the team has something to donate. > > > >-- > >Oleg Tkachenko > >Multiconn International, Israel > > > > > >- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, email: [EMAIL PROTECTED] > > > ' Best, > -Ralph LaChance > > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PDF Viewer] Utility request
At 01:33 PM 7/28/02, you wrote:
>If it helps any, Adobe has a pretty comprehensive Acrobat SDK. Links to it
>can be found at http://partners.adobe.com/asn/developer/sdks.html. I haven't
>had a good excuse to do it myself, but my impression is that if tighter
>integration is required, it could be done using these tools. There is a
>viewer component that can be pulled up inside another application.
Last time I used the Acrobat SDK (1999) it provided support only building
a plug-in to Acrobat Exchange (not free) - ie. adding functionality to Exchange
itself -- things like specialized searching, indexing, or retrieving simple
objects
(including text) from the file, adding work flow, modifying Exchange's menus
etc. It provided NO support for rendering per se, and, more importantly,
had almost no support for modifying the (free) Reader.
Whether one could use a plug-in as a vehicle for tightly bolting acrobat
exchange is an interesting concept, but (in my opinion) we'd not have any
chance to doing anything useful with the reader.
I guess I think that integrating fop with the Adobe engines is a non starter
although I wish that weren't the case.
' Best,
-Ralph LaChance
PS I just (very cursorily) rechecked the api and it does not seem much
changed from what I used in the past.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [PDF Viewer] Utility request
I agree with Oleg's last sentencetotally - which I translate roughly to "lets fix the awt renderer" In fact, I'd add a 3rd (or 2 1/2) user - the one who wishes to go directly from xml to a printer via fop. My colleagues here and I have inserted several changes to tweak spacings, borders, and so on over the past two years, and several other contributors have refined the awt renderer over even more. Recently, I got stumped by a problem in that java's font engine rasterizes glyphs differently depending on whether the target was the on-screen graphics context or a printer context. (see archives) - anyone who could help unsnarl that mess would be making a noteworthy contribution. At 07:59 AM 7/28/02, you wrote: >Matthew L. Avizinis wrote: > It might also be helpful to recognize that as FOP becomes more popular there >>are distinctly _two_ groups of "users" emerging. The first group has been >>using FOP from the beginning and those are the Java developers who use FOP >>to create some other end product. Recently I've noticed that there are more >>people attempting to use FOP who are simply people who want to use FOP as an >>end product (more of an FO viewer) and want it to fulfill the role of a >>product like X-Smiles (which unfortunately still falls far short of its goal >>of being a good FO viewer). > >I believe AWT previewer someday in the future will become some kind of FO >IDE and afaik even nowadays somebody in the team has something to donate. > >-- >Oleg Tkachenko >Multiconn International, Israel > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PDF Viewer] Utility request
Ramana, Two things - in Windows one cannot easily launch the viewer from Java, because there is no command line interface in the Win version of Reader, only DDE - a nuisance (at best) to use via Java. And yes, there is an Adobe-built java-based reader, but it is buggy, is NOT supported, and does not support the new features of present-day Acrobat. Beyond that, good luck writing a PDFEditorKit At 02:03 AM 7/28/02, Ramana wrote: > >Yep, this is OK. My thought was a viewer that can be > 1. Added to the panel component (or) > 2. A PDFEditorKit, as we have HTMLEditorKit. > >Acrobat reader is a outside application. If I launch it through a swing >application, it gives the splash screen etc. etc. The idea is to develop a >viewer which can be part of the swing application. > >Ramana. > > > >Rhett Aultman Wrote: > >I can't speak for others, but this has never been a problem in my time as a >user of FOP. My general FO document development process: > >1) Fiddle with FO document >2) Run through FOP, producing PDF file >3) Point my web browser at the PDF file >4) Web browser launches PDF viewer, either as a plugin or an external >process (depending on if I'm at my Windows or Solaris box) >5) I view the document, closing the external reader, if necessary >6) Go back to 1, except I click the browser's refresh button on 4. > >How much more simple could it get? If it's really that much of a nuisance, >why not write a .BAT file or other form of shell script to run FOP and then >launch a PDF reader to read the file? The process of doing so is fairly >simple and direct. I'm fairly sure that most people using FOP can follow >such a process. > > >-Original Message- >From: RamanaJV [mailto:[EMAIL PROTECTED]] >Sent: Friday, July 26, 2002 5:24 AM >To: [EMAIL PROTECTED] >Subject: RE: [PDF Viewer] Utility request > > >After a little bit of exploration, I found that the JavaBean adobe gives is >not supported at all and the license tell it clear that it could contain >bugs. That JavaBean is not worth talking. When I search the web, I found >that all the activity is going in PDF creation, manipulation etc. etc. There >are good number of API's dealing with it. > >But, how much worth is a creator, without a viewer. In 90% of the >applications the needs come to launch the viewer to be part of the >application. No user prefers the print the PDF outside and again open the >Acrobat Reader to see it. This lessens the competitiveness of the product. >FOP beautifully caters to the creation of PDF, but a viewer is very much >worthy and I'm sure the FOP with a viewer definitely strikes. > >Excuse me, If I'm more user conscious... > >Ramana. > > >-Original Message- >From: Ralph LaChance [mailto:[EMAIL PROTECTED]] >Sent: Friday, July 26, 2002 2:46 PM >To: [EMAIL PROTECTED] >Subject: Re: [PDF Viewer] Utility request > > >At 03:43 AM 7/26/02, you wrote: > >Anyone contacted Adobe to see if they wanna opensource it? > >Two years ago I contacted them to explore source licensing to my >client -- without support -- for usage in a single product and they >couldn't say no fast enough ;-) > >Later I got a back channel email from one of the developers >that mentioned something (I'm not quoting here) about company >loyalties to m$ which made them unwilling to play in the java space. > > > > ' Best, > -Ralph LaChance > > > >- >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] > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PDF Viewer] Utility request
At 12:46 PM 7/25/02, you wrote:
> After seeing the OutOfMemoryError, the AWT renderer is causing, why
>don't thinking of providing a PDF viewer in the FOP itself. I think, this
>will be useful so much. I don't think people couldn't have ever thought
>about it, but is it diffucult to do so?
>I feel, FOP is very much useful with the PDF viewer. What do
>others say?
Seems to me it might be a lot simpler to fix the awt viewer...
Also, oddly enough doing a viewer against pdf is rather tricky -
Adobe put an un-supported java-bean on their web site, but it
is buggy and hasn't been updated in 2 or so years. The only
commercial pkg (a toolset; some assembly required) I know
of probably would pose a licensing challenge (understatement)
' Best,
-Ralph LaChance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: For once Good news and a thank you
At 08:42 AM 6/13/02, you wrote:
>If needed, I can send you a piece of java code that obfuscates the text of
>XML files by replacing all words with others from a list, so that the
>confidentiality of your data would be preserved.
ooo, I could use that !
' Best,
-Ralph LaChance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Fwd: Re: Fop and JDK1.2
Apropos of the many threads discussing 1.3 vs 1.2 code dependencies particularly as it relates to the awt renderer TT fonts, and I might add printing, I repeat my question (below) about ~how not to~ use TT fonts. Plus this: I work from the premise that most users of fop will prefer ~not~ to explicitly configure their own fonts (unless the locale require it) but will take the built-ins -- which to my mind, means those supplied by Java. Would that be an um ~naive~ assumption? >At 12:07 PM 6/10/02, you wrote: >> > 3) Compile Fop with JDK1.3 (which will be done anyway) >> > and state in the release notes that compiling with JDK1.2 >> > and using truetype fonts in the AWT viewer does not work. >> >>Probably the best for the moment. I don't know if some conditional >>compiling is doable. If yes, it probably won't be very maintenance >>friendly. > > >btw: How does one ~prevent~ the use of true type fonts - >isn't that what Java uses for the default font families >(San serif, Serif, etc) on windows ? > >It just occurred to me that the answer to this might be a clue >to solving the awt->printing problem I'm grappling with.. > > ' Best, > -Ralph LaChance > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fop and JDK1.2
At 12:07 PM 6/10/02, you wrote: > > 3) Compile Fop with JDK1.3 (which will be done anyway) > > and state in the release notes that compiling with JDK1.2 > > and using truetype fonts in the AWT viewer does not work. > >Probably the best for the moment. I don't know if some conditional >compiling is doable. If yes, it probably won't be very maintenance >friendly. btw: How does one ~prevent~ the use of truetype fonts - isn't that what Java uses for the defaul font families (Sanserif, Serif, etc) on windoz ? It just occurred to me that the answer to this might be a clue to solveing the awt->printing problem I'm grappling with.. ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP Redesign
At 10:18 AM 6/6/02, you wrote:
>In paticular there is a movement afoot to allow a more dynamic rendering
>of the FOP content using Swing components, as opposed to the current more
>static viewing approach. Support for dynamic changes to the DOM tree (via
>scripting) may also be possible.
+1 here !
' Best,
-Ralph LaChance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: delay for release candidate
At 07:50 PM 6/3/02, you wrote: >Any other patches missing ? Yes, alas, the change I introduced recently which improved the appearance (ie spacing within words) in the awt renderr (command line -awt) introduces a problem with word-to-word spacing in printing -- both when printing from the AWTRenderer's popup dialog and when printing directly via the commandline -print option. NB: I see the problem on NT4.0/sp6 -- I do not know what the results are on different platforms. I have tried many ways to work around the problem all without success. What is worse is that problems seems to manifest itself differently in jdk 1.3.x and jdk 1.4.0. There is sufficient activity on the bug parade in the area of rendering, character spacing and sizing to suggest the problem originates in java - there have been several problems reported about inconsistencies between font metrics and the actual drawing of text by the rasterizer - when the graphics context is that of a printer. If anyone has insight into this area, I'd be glad to take this off-list and try to wrangle out a solution -- but for a week or two, every attempt I've made comes up dry. ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: TIFFRenderer
At 04:31 PM 5/21/02, you wrote: >Are the AWTRenderer spacing fixes in a release version of FOP? If so, which >version? No; but my understanding is that it is now committed to cvs - at least in the maint branch, in what will be the upcoming 0.20.4 maint release. The change is confined one method (renderWordArea) in ...fop.render.awt.AWTRenderer. ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: TIFFRenderer
At 10:11 AM 5/21/02, you wrote:
>Ralph LaChance is working on it. Check the current CVS. Ralph's diff
>should have improved some of this. But it seems like AWT still has its
>pitfalls.
>
>Implementing a full bitmap renderer without the use of AWT would be a
>major pile of work, I think. But you can always try to use GhostScript
>to convert a PDF/PS to TIFF which should have about the same qualities
>as the PDF. Which method are you using right now?
Actually, I (biased!) think the present awt renderer is quite good; the
character spacings problems within words that existed in previous versions
is fixed, and text decorations seem to work correctly.
As Jeremias pointed out, I am chasing a new problem - but that one doesn't
really bear on awt itself, but shows up only when the awt renderer is used
to print. (The problem appears if fop is run w/ -print option or if the print
command is invoked on the -awt display dialog.)
Offhand, I do not expect the printing problem to show up if the awt
renderer were used as the basis for a tiff renderer.
We believe the printing problem stems from a java bug around fonts -
the character rasterizer seems to be ending up with text strings being
improperly sized when it is drawing into a graphics context created by
a PrinterJob. There are several related bugs in the bug parade on this
matter.
' Best,
-Ralph LaChance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Font Metrics AWT
At 05:15 PM 5/19/02, you wrote: >There may be still an issue about the actual vertical >position of an overline. Yes, I expect so; since java.awt.Font contains no specification for where to put the underline (as I pointed out in my code comments.) Unfortunately my word processor doesn't know about overlines, so I can't even suggest a precedent. btw: On my wp, the top of a superscript appears to lie 1 or 2 graphics units above the uppercase ascender; I guess I'd try putting the overline a hair above that. >And there are sporadic hiccups with the inline >space text decorations which probably are a result of poor rounding. >I haven't found out yet. I don't doubt that - you might notice several places in AwtRenderer (marked aml/rlc) where we tweaked the integer arithmetic slightly to avoid such hiccups. On the larger issue of printing, I've made no progress yet; am hoping to get to it in a day or two; btw: I noticed that in another post Peter is testing expectations for 0.20.4 -- at the very least, when that starts getting real, it will light a fire under me re printing. ;-) Thanks for your help. ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Font Metrics AWT
At 05:18 PM 5/19/02, you wrote: >Oh my. I seem to have been too fast on this, maybe. Anyway, I'm going to >bed now. Well, in my opinion, the previous change ~should~ be committed as you did, since what we had was clearly not right. Whatever happens next to solve the new problem w/ printing should be applied separately. Thanks! ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Font Metrics AWT
Heads up: Unfortunately, the saga continues The change to AWTRenderer that I recently submitted does indeed fix problems with -awt but as a side effect, it introduces new problems with printing. For example, if you render a page via -awt (with the changed code) the rendition looks fine; then, if you print it directly from the -awt dialog (via menubar) you get some words overlapping one another on a given line. You get the same overlapping by going directly to the printer via -print. Just to keep it fun: not all fonts, nor all sizes fail. I suspect the results may differ by platform and printer too ! I am researching the bug parade and java groups like crazy to find a way through this -- So far, I've learned there ~is~ a known inconsistency (apparently since jdk 1.3.0) between the jre's use of screen fonts vs printer fonts. One Sun bug evaluator mentions that Swing's caching of fonts is also a contributor. This affects fop because we does our printing via a subclass of the awt renderer. The simplest way to explain what is happening is this: draw a string into a graphics2D that will be printed then draw a rectangle using the rectangle returned by .getVisibleBounds In many cases the bounding rectangle does not match the drawn text. The bounding rectangle is usually shorter than the drawn text - - the end result in fop, is that words overlap. The mismatch is a function of font -- and even worse -- also seems to depend on recent font usage (jre caching?) btw: In my testing, the actual bounding rectangle returned by getVisibleBounds() seems to match the internal spacings derived in and used by the fop layout engine - so this appears to be an actual printing problem, not a metrics problem. -ralph At 04:13 AM 5/17/02, you wrote: > >Hi all > >Great work Ralph. >The results looks very good and I hope the next release contains your fix. > >I've and additional wish for the AWTRenderer. >Can anyone make the 'graphic' variable protected, to enable sublasses to >draw on it? >In my case I have to divide between final print and test print (crisscross >the page and draw a test string on it). At this time I have to do it twice >(without patching original sources). Firtsly at renderPage(Page) where I >create my own Graphics2D instance after super.renderPage(Page) has finished >and secondly on print with the passed in Graphics2D parameter. >I think programmer who subclass the original know that they have to work >with the graphics variable careful and are responsible for their own >mistakes. Therefore I don't see a reason to hold the instance restrictively >with private access. > >ThanX a lot (especially to ralph for the fix) >cu Torsten > > > -Original Message- > > From: Ralph LaChance [mailto:[EMAIL PROTECTED]] > > Sent: Donnerstag, 16. Mai 2002 17:05 > > To: [EMAIL PROTECTED] > > Subject: RE: Font Metrics AWT > > > > > > I have found the problem and worked out its repair. > > The modified code is attached below. > > > > The problem stems from a bug in java's handling of drawing of > > AttributedStrings when a font attribute is specified. Bug parade > > #4650042 describes a similar problem unique to jdk 1.4, but > > makes also suggests that there are other more general problems > > w/ fonts and AttributedStrings. > > > > In our case, calling > > drawString (string) instead of > > drawString (AttributedString...) solves the problem. > > > > The fix simply draws the text using the string version of > > drawString and then to draw the underline (if defined) > > separately. > > > > I have tested it on jre 1.3.0, jre 1.3.0_02 and jre/jdk 1.4.0 - > > all on WinNT4/sp5 > > > > attached is the changed code -- it only affects one method > > in AWTRenderer. > > > > Will someone commit it ? > > > > >x--snip >... >x--snap > > > > > > ' Best, > > -Ralph LaChance > > > > > > >- >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: Font Metrics AWT
At 04:13 AM 5/17/02, you wrote:
>Can anyone make the 'graphic' variable protected, to enable sublasses to
>draw on it?
Makes sense to me; since I'm not a committer, it doesn't make much
sense for me to make the change - perhaps whoever commits my new
version of AWTRenderer.renderWordArea() would make that change too.
(Christian or Arved have handled my previous suggestions.)
' Best,
-Ralph LaChance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Font Metrics AWT
I have found the problem and worked out its repair.
The modified code is attached below.
The problem stems from a bug in java's handling of drawing of
AttributedStrings when a font attribute is specified. Bug parade
#4650042 describes a similar problem unique to jdk 1.4, but
makes also suggests that there are other more general problems
w/ fonts and AttributedStrings.
In our case, calling
drawString (string) instead of
drawString (AttributedString...) solves the problem.
The fix simply draws the text using the string version of
drawString and then to draw the underline (if defined)
separately.
I have tested it on jre 1.3.0, jre 1.3.0_02 and jre/jdk 1.4.0 -
all on WinNT4/sp5
attached is the changed code -- it only affects one method
in AWTRenderer.
Will someone commit it ?
At 09:12 AM 5/10/02, you wrote:
>
>Hi all!
>
>Now I've downloaded the sdk version 1.3.1_03 from sun but the result is the
>same like before.
>I've attached a screenshot to this mail.
>My workflow:
>I go to the Driver, set the Logger and my Renderer(extended from
>AWTRenderer), and call render(XMLReader,InputSource) on the Driver,
>After that I go to my Renderer and render each page in a loop and add the
>result within a JLabel to a JPanel, which is showing for the User.
>
>code piece:
>
>driver.render( parser, inputHandler.getInputSource() );
>
>for (int i = 0; i < renderer.getNumberOfPages(); i++)
>{
> renderer.render(i);
>
> JLabel label = new JLabel( new ImageIcon(
>renderer.getLastRenderedPage() ) );
>
> panel.add( label, new GridBagConstraints(0, i, 1, 1, 0.0, 0.0
> ,GridBagConstraints.WEST, GridBagConstraints.NONE, new
> Insets(6, 6, 6,
>6), 0, 0));
>}
>
>the result is below
>
>Can anyone help me or tell me my mistake?
>
>ThanX Torsten
>
>-----
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, email: [EMAIL PROTECTED]
' Best,
-Ralph LaChance
AWTRenderer.renderWordArea.zip
Description: Zip archive
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Font Metrics AWT
Trying to place your results on a JLabel rings a bell but I can't
recall why
Could you try running the vanilla command-line fop -awt and
see if you get better results ?
something like
java -cp
org.apache.fop.apps.Fop
-xsl -xml -awt
Also, please give you fop version , os ? , the usual stuff
(hmmm, perhaps I'm showing my age in more ways than one; I cannot
recall if the current maintenance branch still has a command-line invocation.
Our production usage is based on fop 0.20.1)
At 09:12 AM 5/10/02, you wrote:
>
>Hi all!
>
>Now I've downloaded the sdk version 1.3.1_03 from sun but the result is the
>same like before.
>I've attached a screenshot to this mail.
>My workflow:
>I go to the Driver, set the Logger and my Renderer(extended from
>AWTRenderer), and call render(XMLReader,InputSource) on the Driver,
>After that I go to my Renderer and render each page in a loop and add the
>result within a JLabel to a JPanel, which is showing for the User.
>
>code piece:
>
>driver.render( parser, inputHandler.getInputSource() );
>
>for (int i = 0; i < renderer.getNumberOfPages(); i++)
>{
> renderer.render(i);
>
> JLabel label = new JLabel( new ImageIcon(
>renderer.getLastRenderedPage() ) );
>
> panel.add( label, new GridBagConstraints(0, i, 1, 1, 0.0, 0.0
> ,GridBagConstraints.WEST, GridBagConstraints.NONE, new
> Insets(6, 6, 6,
>6), 0, 0));
>}
>
>the result is below
>
>Can anyone help me or tell me my mistake?
>
>ThanX Torsten
>
>-----
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, email: [EMAIL PROTECTED]
' Best,
-Ralph LaChance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
wrong lists - 2cents
Just my random, well-intentioned 2 cents on the frequency with which "user" questions show up here. Mind you, I don't find them all that annoying; some - including me - would say it doesn't hurt to have "developers" see what the real world is up to. But I have noticed that increasingly folks show signs of having been told (off list) that they're asking in the wrong place. I can't help but wonder if some of the user questions that stray onto this list do so because of confusion engendered by the list names. I can imagine someone thinking "ah, I, a developer building a fop app, need help; I'll send my question to this here fop-dev list" I could go on about the disinclination of certain red-blooded developers to ever believe they are a "user" but maybe I won't go there ;-) Perhaps a simple rename of the current fop-dev to Fop-internals would help ? btw Some might say the web page is pretty explicit about which list is which - to which I might say "and your point is ?" 'best -Ralph LaChance Oh my, I hope this doesn't launch a firestorm ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
pdf bean
Hello,
Somewhat off topic, but since this shapes up as the largest collective body
of pdf-ers outside of Adobe, I hope not to offend.
Anyone know of a pdf-rendering components (java) ?
Some time ago (2 years?) Adobe released a beta bean without support.
While it is buggy, it one is careful, it will do a good job of rendering basic
pdf content on a Component (or Canvas). The bean has not been updated
since then; it remains unsupported by Adobe, and -- several exchanges
with Adobe later -- I know of no way to obtain source short of decompilation.
Does any of you know of another candidate component ? I've cast a large
net to no success, but perhaps I missed something obvious.
We've even tried to imagine using Adobe's browser plugin, but we
can't quite get there.
Goal is simple: take a pdf file and render it in a Component or JComponent.
(btw: Starting from xml in the general case is not an option, so although we
use fop in production, it won't serve here.)
Thanks for any suggestions
'best
-Ralph LaChance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)
I'm wondering if marying FOP +iText would sacrifice the -awt -print -ps options. (Same question for -text, but i'm personally not interested in that.) At 10:58 AM 3/13/02, you wrote: > >Given what has been said on the mailing lists of FOP and iText, and given >the current scope of the two projects, I feel reasonably sure that this >could be a proposal accepted by bot communities. > >- > FOP uses iText as a PDF generation library >- > >This could have greater benefits than a merger and keep intact the strenghts >that these two projects have (remember AOL+Time Warner? is the result we >want?). > >iText could continue to be an excellent PDF (and RTF AFAIK) generation >package with a good java API. >FOP could concentrate on FO2AreaTree and use iText as the last step. > >Given the licences, nobody is prohibited to cross-collaborate. iText >developers can send patches to FOP and viceversa, and be [VOTE]d as usual >when the time is right. >FOP can distribute iText jar as it's MPL, and both projects would cross-link >in a clear way. > >AFAIK iText is already able to produce PDF using an XML file. If FOP could >make a transformation step from FO to this format, we could get this up >running in a short time. >And IText can also output to html, which is not bad at all. > >What do you think? >Shall we pull this off? > >-- >Nicola Ken Barozzi [EMAIL PROTECTED] > - verba volant, scripta manent - >(discussions get forgotten, just code remains) >- > > >----- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOP Print Option
At 10:38 AM 3/11/02, you wrote: >I figured out how to tell FOP to print to a specified printer. On Windoze, >depending on if you have a postscript printer or PCL printer you can simply >do: >fop ... -ps \\computername\printer or fop ... -pcl \\computername\printer. > >Jim but remember that -pcl doesn't do color (at least it didn't) ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP Print Option
At 03:53 PM 3/8/02, you wrote: >I need to use the FOP print option (-print) to print a FO directly to a >printer. The problem is, I need to tell FOP which printer (by name, port or >UNC name) to print to. Displaying the preview window (-awt) or printer >dialog is not an option. I will be embedding this code in an application >which will run unattended. The application will "wake up", check for FOs to >print and print them automatically without any user intervention and then go >back to sleep. The print out must go to a specified printer containing a >special paper which will most likely NOT be the default printer. Any ideas >how to do this? This was answered previously, please check the archives. The short answer is that you cannot in any straightforward fashion programmatically assign a printjob to a specific printer pre-Java 1.4. There new JavaPrintService facility in 1.4 is promising, but I think you might have trouble trying to run fop in 1.4 yet. If someone wishes to "refine" this answer, please jump in; Alex -- another topic for the faq? ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP Interfaces
At 05:11 PM 2/27/02 +0100, you wrote: >renderer options >- embedding fonts >- compression in pdf >- image embedding > > >The Driver handles the XML input. >The user agent information is through the FOUserAgent. >We could handle logging through the user agent. >Options could also be handled through the user agent, using mime type >selection for renderer options. > >So, what do people think. What other information will be needed. Keiron, my 2 cents, shot from the hip ;-) Based on both our fop usage here and on dozens of questions I've seen go by on this list, perhaps it makes sense to consider some support for driving various printing options. i.e., put up the dialog, default to std printer, etc. Clearly the options are very different for a servlet vs an application. Also, in view, of the new PrinterServices facility in 1.4, perhaps some thought to allowing the calling framework (servlet or app) to specifying the printer. And then there is the recurring question of whether -awt generates a panel or a frame and whether it returns a swing object or not. ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Seeking Comments on Status of Project
At 07:31 AM 2/6/02 +0100, you wrote: >I think that most people need some encouragement to take the > > plunge in murky waters and since so many seem to feel generous this week, allow me to toss my hat into the ring - we would be pleased to help out with the awt renderer and the print renderer -- even to the extent of hooking it up to the jdk1.4 PrintService when fop takes the 1.4 plunge. However, we'd best have someone else to provide the backend support for those functions common to all renderers for traversing the data model etc. ' cheers -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Why do you use FOP instead of ...
It does seem a shame that this entire quo vadis thread
isn't on fop-user
' Best,
-Ralph LaChance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Why do you use FOP instead of ...
At 04:06 PM 2/1/02 -0200, you wrote: >I will nail down the weaknesses of the XML->PDF approach: > >1. XSL:FO is a very complicated and messy language >2. XSLT is also kinda complicated to use, at least if you have to do >complicated formatting... Sometimes it seems folks assume that FO is synomous with "pdf", but for some of us, the point of using FO is not to create pdf output but to format and send xml data directly to a printer. ;-) ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Server and Batch Reports with FOP
At 04:28 PM 1/29/02 +0100, you wrote:
>Is there anyone working with FOP who made experience with a serverside
>solution for printing the pdf-Files ?
>Is there a tool for that ?
Here is an example I submitted to this list about 2 weeks ago.
I have tested it w/ a servlet runner on Windows only.
' Best,
-Ralph LaChance
/*
* $Id: FopServlet.java,v 1.4 2001/09/25 08:32:58 keiron Exp $
* Copyright (C) 2002 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
*/
import java.io.*;
import java.util.Vector ;
import java.awt.print.PrinterJob ;
import java.awt.print.PrinterException ;
import javax.servlet.*;
import javax.servlet.http.*;
import org.xml.sax.InputSource;
import org.xml.sax.XMLReader;
import org.apache.fop.apps.Driver;
import org.apache.fop.layout.Page;
import org.apache.fop.apps.Version;
import org.apache.fop.apps.XSLTInputHandler;
import org.apache.fop.render.awt.AWTRenderer ;
import org.apache.log.*;
/**
* Example servlet to generate a fop printout from a servlet.
* Printing goes to the default printer on host where the servlet executes.
* Servlet param is:
*
* fo: the path to a formatting object file to render
*
*
* Example URL: http://servername/servlet/FopPrintServlet?fo=readme.fo
* Example URL: http://servername/servlet/FopPrintServlet?xml=data.xml&xsl=format.xsl
* Compiling: you will need
* - servlet_2_2.jar
* - fop.jar
* - sax api
* - logkit jar
*
* Running: you will need in the WEB-INF/lib/ directory:
* - fop.jar
* - batik.jar
* - avalon-framework-4.0.jar
* - logkit-1.0b4.jar
* - xalan-2.0.0.jar
*/
public class FopPrintServlet extends HttpServlet
{
public static final String FO_REQUEST_PARAM = "fo";
public static final String XML_REQUEST_PARAM = "xml";
public static final String XSL_REQUEST_PARAM = "xsl";
Logger log = null;
public void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException
{
if (log == null)
{
Hierarchy hierarchy = Hierarchy.getDefaultHierarchy();
log = hierarchy.getLoggerFor("fop");
log.setPriority(Priority.WARN);
}
try
{
String foParam = request.getParameter(FO_REQUEST_PARAM);
String xmlParam = request.getParameter(XML_REQUEST_PARAM);
String xslParam = request.getParameter(XSL_REQUEST_PARAM);
if (foParam != null)
{
FileInputStream file = new FileInputStream(foParam);
renderFO(new InputSource(file), response);
}
else if ((xmlParam != null) && (xslParam != null))
{
XSLTInputHandler input = new XSLTInputHandler(new File(xmlParam), new
File(xslParam));
renderXML(input, response);
}
else
{
response.setContentType ("text/html");
PrintWriter out = response.getWriter();
out.println("Error\n"+
"FopServlet ErrorNo 'fo' or 'xml/xsl' "+
"request param given.");
}
}
catch (ServletException ex)
{
throw ex;
}
catch (Exception ex)
{
throw new ServletException(ex);
}
}
/**
* renders an FO inputsource into a PDF file which is rendered
* directly to the response object's OutputStream
*/
public void renderFO(InputSource foFile, HttpServletResponse response)
throws ServletException
{
try
{
Driverdriver = new Driver(foFile, null);
PrinterJobpj = PrinterJob.getPrinterJob();
PrintRenderer renderer = new PrintRenderer(pj);
driver.setLogger (log);
driver.setRenderer(renderer);
driver.run();
reportOK (response) ;
}
catch (Exception ex)
{
throw new ServletException(ex);
}
}
public void renderXML(XSLTInputHandler input, HttpServletResponse response)
throws ServletException
{
try
{
Driverdriver = new Driver();
PrinterJobpj = PrinterJob.getPrinterJob();
PrintRenderer renderer = new PrintRenderer(pj);
pj.setCopies(1);
driver.setLogger (log);
driver.setRenderer (renderer);
driver.render (input.getParser(), input.getInputSource());
reportOK (response) ;
}
catch (Exception ex)
{
throw new ServletException(ex);
}
}
// private helper, tell (browser) user that file printed
private void reportOK (HttpServletResponse response)
throws ServletExcept
RE: [ANNOUNCEMENT] FOP 0.20.3 Release Candidate available
Arved et al,
Any interest in including the printing servlet example I submitted last week:
...\examples\FopPrintServlet
It doesn't appear to be in the current rc.
' Best,
-Ralph LaChance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
quo vadis - RE - launch Acrobat Reader invisible
Hi all, I'm a little confused about this exchange -- and wondering what is driving the interest in directly launching AcrobatReader ? We run fop and generate printouts directly using the -print option all the time and get 100% fidelity viz-a-viz producing pdf files from fop and then (manually) printing them. (Checked with a light table even!) We happen to be doing our production work via a shell command since the spawning application is in smalltalk, but we've also verified the approach runs just fine when we invoke fop directly via method calls from within a Java app (We simply inspected the command processor source and mimic'd what it does for -print.) We use standard fonts, as it turns out, but do embed gif's, generate 2 column text layouts with in-line column-spanning tables (whose contents include some column spanning data) and the results are just fine. I concede that -print only goes to the default printer and I'll admit that we needed to tweak the xslt to workaround certain "sensitivities"; but we're OK with that. We have a 100% cross platform solution and it isn't sold by micro$oft. >I think that all this system calling is a bit dodgy if you don't control the >target environment: I looked at it for a while but felt that I couldn't >prevent things going badly confusing for the user if they had any deviance >in their setup. > >And it obviously throws away the cross-platform nature of things. > >Nobody interested in the AWTRenderer / PrinterJob pure java approach? Even >lets you do the print dialog thing... ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: launch Acrobat Reader invisible
At 10:46 AM 12/13/01 +0100, you wrote:
>this document is "C:\Programfiler\Adobe\Acrobat 5.0\Acrobat\Acrobat.exe"
>/p /h "%1".
Hmmm, my installation is set up to use DDE to pass a filename
to acrobat. The DDE command is
FilePrintSilentEx("%1")
' Best,
-Ralph LaChance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Advice please
At 01:11 PM 12/5/01 +, you wrote: >2. build in printing direct from FOP. > >My problems with the above are: > >2. I've made this work but I get different results - presumably becuase of >differences in the renderer. What do you mean by "different results" is it just a matter of sizing or are there other differences ? If the problem can be traced to differences in sizing: is it possible that you are getting different results because your acrobat reader is set up with the option "fit to page" turned on ?We wasted a day or so tweaking the sizes on our pdf output only to have -print look different for that reason. fyi We're getting excellent results using fop 0.20.1 and the -print option. Our application produces only a single page, but it is a complex layout with tables etc. I wouldn't be surprised if your output is similar in structure. In our case, the print outs created from fop's pdf output exactly match the printouts created directly by fop. I Hope this helps. ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Warning: breaking cvs
At 11:18 AM 10/22/01 +0200, you wrote: >The renderers are missing most of their code. This will be readded as >appropriate in an attempt to make the renderers cleaner and simpler. Keiron, If it would help, after you've roughed out most of the PDF renderer, my group (Andy and I) would be willing to take some time to help fill in the awt and/or print renderers, following the pattern you establish. I'm following the dialogs here, but have been mostly silent lately, do feel free to wake me up when and if you wish. ' Best, -Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: pdf viewer
At 07:35 AM 10/9/01 -0700, you wrote:
>I want to pass the pdf file created by fop to a java pdf viewer within
>an application. Can anyone recommend a viewer that can be embedded in a
>java app
The acrobat viewer bean distributed by Adobe ~works~ -- but not, I think,
without doing some work yourself. We had to drop down to a lower level of
interface from the top level "bean", use primitives to convert a PDF to an
Image and then render the image ourselves on a panel w/ our own menus,
editor kit and the like.
The relevant Adobe classes are (taken from our imports)
import com.adobe.acrobat.PDFDocument;
import com.adobe.acrobat.sidecar.FloatPoint ;
import com.adobe.acrobat.sidecar.AffineTransform ;
If you want the gory details, fee free to contact me off-list
and I'll send 'em along. Our implementation requires
Swing and Java2D.
' Best,
-Ralph LaChance
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] Enhanced FOP Ant Task
At 11:04 AM 9/24/01 +0200, you wrote: >I didn't include support > > for "-awt" and "-print", though. "-awt" IMHO makes not much sense in > > this context, does it? As for "-print" I was simply too lazy. Maybe you > > want to look at this yourself, Ralph. Sorry. happy to (later this week) ;-) ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] Enhanced FOP Ant Task
I stepped into this thread late in the game, but what about equivalencies for -awt and -print. Seems to me that -print is presently the only way to silently drive a printer from fop on all platforms. At 03:26 PM 9/19/01 +0200, you wrote: > >Sure, good idea. I'm going to do that on Friday and repost the patch. > >So the changes will be (if I got everything right): >pdf --> application/pdf >ps --> application/postscript >mif --> application/vnd.mif >pcl --> application/vnd.hp-PCL >txt --> text/plain >at --> text/xml > > >On Wed, 19 Sep 2001 14:59:24 +0200 Keiron Liddle wrote: > > > > Would it be possible/suitable to define the output type using a mime type. > > ie. application/pdf > > rather than having our own definition. > > > > On Wed, 19 Sep 2001 14:24:41 Jeremias Maerki wrote: > > > Hi there > > > > > > I've done some tinkering with the FOP Ant Task, that I'd like to submit. > > > Currently the FOP task can only generate PDF. I changed it so it can > > > use the other renderers as well. > > > > > > Old syntax: > > > > > > > > > New syntax: > > > > > > or > > > > > > > > > The "renderer" attribute is optional and defaults to "pdf". Possible > > > values currently are: "ps", "mif", "pcl", "txt" and "at" (AreaTree XML). > > > > > > Attached you find the diff for the Ant Task along with the various > > > updated build.xml files. > > > > > > By the way: It seems that the xml-docs cannot currently be built. I get > > > an infinite number of ">" after page 20. I didn't investigate any > > > further. > > > > > > Cheers, > > > Jeremias Märki > > > > > > mailto:[EMAIL PROTECTED] > > > > > > OUTLINE AG > > > Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern > > > Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029 > > > Internet http://www.outline.ch > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > >Freundliche Grüsse >OUTLINE AG >Jeremias Märki > >mailto:[EMAIL PROTECTED] > >Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern >Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029 >Internet http://www.outline.ch > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Borders not lining up
oops, sorry. Didn't realize Art meant the "fit to page" option on the Acrobat ~print~ dialog. He's right, that does the trick. (blush) At 09:59 AM 8/22/01 -0400, you wrote: >Art, > >I just took a pdf file I used for a test I reported yesterday and >1-by-1 set Acrobat 4.0 (on NT) to View>Actual size, >View>FitWidth, View>FitVisible and View> FitInWindow and >printed each. > >In all cases the printouts were identical, specifically, several tables' >on 1 page are all rendered 6-7% undersize compared to running >fop -print or fop -awt (and pressing the Print button) > >At 05:25 PM 8/21/01 -0400, you wrote: >>I just thought that I would mention that I had problems with Acrobat not >>printing PDFs in the size that I expected, until I discovered (and turned >>off) the fit to page option. > > > ' Best, > -Ralph LaChance > > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Borders not lining up
oops, sorry. Didn't realize Art meant the "fit to page" option on the Acrobat ~print~ dialog. He's right, that does the trick. (blush) At 09:59 AM 8/22/01 -0400, you wrote: >Art, > >I just took a pdf file I used for a test I reported yesterday and >1-by-1 set Acrobat 4.0 (on NT) to View>Actual size, >View>FitWidth, View>FitVisible and View> FitInWindow and >printed each. > >In all cases the printouts were identical, specifically, several tables' >on 1 page are all rendered 6-7% undersize compared to running >fop -print or fop -awt (and pressing the Print button) > >At 05:25 PM 8/21/01 -0400, you wrote: >>I just thought that I would mention that I had problems with Acrobat not >>printing PDFs in the size that I expected, until I discovered (and turned >>off) the fit to page option. > > > ' Best, > -Ralph LaChance > > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Borders not lining up
Art,
I just took a pdf file I used for a test I reported yesterday and
1-by-1 set Acrobat 4.0 (on NT) to View>Actual size,
View>FitWidth, View>FitVisible and View> FitInWindow and
printed each.
In all cases the printouts were identical, specifically, several tables'
on 1 page are all rendered 6-7% undersize compared to running
fop -print or fop -awt (and pressing the Print button)
At 05:25 PM 8/21/01 -0400, you wrote:
>I just thought that I would mention that I had problems with Acrobat not
>printing PDFs in the size that I expected, until I discovered (and turned
>off) the fit to page option.
' Best,
-Ralph LaChance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [Bug 3208] New: Blocks aligned incorrectly in PDF
At 10:35 PM 8/21/01 +0200, you wrote:
>regarding the first problem: are you printing under windows with acrobat
>reader 4.0 and up? Try printing on a different printer. I have similar
>problems with WinNT and Acrobat Reader 4 an 5 when I am printing to a HP
>LaserJet 4M+.
fyi
The tests I ran (different from Steve's, reported earlier here, showing
6-7% shrinkage) are on an HP DeskJet 1175 cse.
' Best,
-Ralph LaChance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Borders not lining up
Which renderer are you using i.e., in your command line are you using -awt, -pdf, -print ? I just ran a quick test on 0.20.1 on a test case that renders several 6 inch-wide tables on a single page. In cases, the source is xml, transformed via xslt within fop. The results (apologies to all you metric folks) bot fop -awt (and pressing using the print button) and fop -print both yield a page with all the tables exactly 6 inches wide. running -pdf and printing the resulting pdf file via Acrobat 4.0, the tables are all 5 5/8 inches. These results pretty much agree w/ Steve's results. These results on WinNT. (I regret to say we noticed this a month ago, but since it didn't affect our needs, we didn't report it. tsk tsk) At 02:26 PM 8/21/01 +0100, you wrote: > >Hi, > >Firstly, ... am I in the right place for queries of this nature ? (I've >tried fop-dev-help & fop-dev-info already !) > >I'm completely new to FOP and just getting to grips with the examples >provided, so I'm probably going to sound really dumb. > >I've been running through the samples provided in the FOP directories and >I've noticed that, in the example "border.fo", there seem to be a few >anomalies: >* the measurements do not seem to add up either horizontally or >vertically; >* in the section which defines the address/Sold To/Ship To etc., once >I've established where I think the "zero" edge is, the "left" or "top" edges >of the block definitions just don't seem to measure up ! >* in the table definitions, the 4 column widths add up to 19cm but >physically they only print about 17.9cm ! >* the text in some of the columns (of the table) seem to "creep" over >to the left even though "end" alignment is specified; >I've used the white-space-collapse="false" option to see if that makes any >difference - but that doesn't help; >It seems to be affected by the length of the text in an earlier column >(Description); padding the shorter descriptions with spaces "seems" to help >a bit, but not totally; and using the monospace font doesn't seem to have >made any difference either. > >So, am I doing something incredibly stupid or this a "feature" that I have >to work around ? > >Thanks, > >Steve McCardle > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: How to monitor fop-dev without overloading my mailbox?
At 09:03 AM 8/15/01 +0100, you wrote:
>I think there is a need for a batched fop-dev email subscription so that you
>get one message a day with loads of messages inside it. I haven't seen the
>method
>for doing this with this list though. If there is a way then perhaps that will
>help...
Some of the Sun mailing lists (c.f. Java 2D) have a "daily digest" mode in
which
you get one email daily with everything appended together in order of arrival.
Perhaps that software is available ? The downside to the digest is that it
becomes
very hard to reply to an individual msg, preserving multi-level >, >>
markers etc.
' Best,
-Ralph LaChance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: QUERY: Why doesn't PrintRenderer use the addLine routines for borders.
We will check whether any of the changes we made to AWTRenderer (the -awt and -print options) should be reconsidered w/r/t/ the dashed line style mentioned below. I'm mostly on vacation and Andy is out of town for the next week, so it'll be the Aug 25th before we can look at it. At 09:27 AM 8/15/01 +1200, you wrote: > >Instead it uses the fillRect routines. > >Unfortunately, I needed to have a dashed border (in PDF's) and so put back >(well not exactly hence the query) the old ways. Which seems to work fine >(for me). > >If the reason for the change was that some of the other renderers couldn't >cope, perhaps their addLine routines could be changed to redirect to the >fillRect ones. > >In any case, could the other line styles please be restored to FOP-PDF. > >Here is the diff of org.apache.fop.render.PrintRenderer of what I've done >(between the ''s): > > >364c364,365 >< addFilledRect(rx, ry, w, top, >--- > > addLine(rx, ry, rx + w, ry, top, > > bp.getBorderStyle(BorderAndPadding.TOP), >365a367,369 > > // addFilledRect(rx, ry, w, top, > > // new >PDFColor(bp.getBorderColor(BorderAndPadding.TOP))); > > >367c371,372 >< addFilledRect(rx - left, ry - h - bottom, left, h + top + >bottom, >--- > > addLine(rx, ry - h, rx, ry, left, > > bp.getBorderStyle(BorderAndPadding.LEFT), >368a374,376 > > // addFilledRect(rx - left, ry - h - bottom, left, h + top + >bottom, > > // new >PDFColor(bp.getBorderColor(BorderAndPadding.LEFT))); > > >370c378,379 >< addFilledRect(rx + w, ry - h - bottom, right, h + top + >bottom, >--- > > addLine(rx + w, ry - h, rx + w, ry, right, > > bp.getBorderStyle(BorderAndPadding.RIGHT), >371a381,383 > > // addFilledRect(rx + w, ry - h - bottom, right, h + top + >bottom, > > // new >PDFColor(bp.getBorderColor(BorderAndPadding.RIGHT))); > > >373c385,386 >< addFilledRect(rx, ry - h - bottom, w, bottom, >--- > > addLine(rx, ry - h, rx + w, ry - h, bottom, > > bp.getBorderStyle(BorderAndPadding.BOTTOM), >374a388,389 > > // addFilledRect(rx, ry - h - bottom, w, bottom, > > // new >PDFColor(bp.getBorderColor(BorderAndPadding.BOTTOM))); > > >TTFN > >Struan Judd <*> "And so it begins ..." ICQ: 4498196 >http://neongraal.sf.org.nz >mailto:[EMAIL PROTECTED] Voicemail and Fax: +1 (201) >305-1011 x1006 > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Newbie question: FO files
At 04:03 PM 8/8/01 +0100, you wrote:
>If I understand it right, the problem is my XSL-stylesheet. The XML uses a
>DTD which makes conform XML-files, so this shouldn't be the problem. So I
>have to create a XSL-Stylesheet which is compatible with FOP. Am I right? If
>so, where can I find specifications?
As long as I'm flogging books:
XSLT 2nd Ed by Michael Kay covers everything you've asked,
(and then a whole lot more...)
' Best,
-Ralph LaChance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Newbie question: FO files
At 03:29 PM 8/8/01 +0100, you wrote:
>Now, what are Fo-files? (I said I was a newbie!)
>Can I transform my XML into those .fo-files?
>
>Thanx, any help is appreciated!
I suggest you start here -- it is part I, with a link to part II
http://www.xml.com/lpt/a/2001/01/17/xsl-fo/index.html
Then follow up with this excellent chapter from a book
by Elliotte Rusy Harold (a correspondent on this list)
http://www.ibiblio.org/xml/books/bible2/chapters/ch18.html
better yet, buy it ;-)
' Best,
-Ralph LaChance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Problems running FOP
At 02:21 PM 8/8/01 +0200, you wrote: >As I haven't been able to get FOP running on Windows ME system, I worry >that perhaps extracting the UNIX .tar files on Windows introduces subtle >corruptions. Could someone clarify why Windows ZIP downloads are no longer >available? > >Please remember that we Windows ME users suffer from MS brain jamming, and >are irrationally frightened of non-Windows things... ;-) Would you be more comfortable knowing that WinZip handles tar files just fine ? As for brain jamming, they must have a bug in the code - the more they do to me, the more I hate 'em. Maybe they'll get it right in version 3.1 ;-) ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: tables with margins and borders
At 06:53 PM 8/7/01 +0200, you wrote: >Koen (and Ralph and others), > >There is a problem, but it's not a border-drawing problem. Karen, Sorry, I wasn't clear -- I'm suggesting there are ~two~ separate problems here. The first is what you describe below. The second is: given the fo such as it is, it renders differently for -print and -awt versus -pdf. On both -awt and -print no border is drawn for the table cells. The pdf renderer ~does~ draw the table borders. The awt/print problem is due to AWTRenderer attmpting to fill a rectangle with either the width or height of zero. This happens when the border size drops below a threshold (i.e., 500 millipts) This all stems from a patch to AWTRender I supplied a few weeks ago in which, among other things, we made AWTRenderer honor actual border sizes. (The original 0.19.0 AWTRenderer drew ~all~ borders 1 pixel thick, regardless of border-size.) Does this make sense to you ? If so, I supplied a patch earlier today to fix it. >You have a left-margin specified as 2cm on a block which is containing >the paragraphs before the table and the table itself. This property is >inherited and is therefore used on both the fo:table and the fo:blocks >inside the fo:table-cell objects. > >What isn't normal is that the table itself should be indented by 2cm and >it isn't. But that in itself won't fix the cell text alignment, since >the margin (or start-indent which is the same thing) is being inherited >by all the content inside the table. So the cell content would still be >badly positioned. > >Assuming that FOP handled indent correctly on the table, you would want >to set it back to a smaller value, on table-body for example. > >In the meantime, there is an ugly workaround involving an empty first >column whose width is equal to the current indent and which only has >borders on the right side. > >As Arved has just suggested focusing on tables, this problem will be a >good place to start and I'll try to put it on the high priority list. ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
AWTRenderer patch
Hi,
Below is a patch to prevent AWTRender from drawing an invisible
border when the value for border-width is too small. The patch
basically says that no matter how small the border-width is, it will
always render at least 1 pixel on the target graphics context.
I leave it to others to rule on the correctness of this approach
(makes sense to me) and thereby commit the patch or not.
Note however that for the sample fo attached,
(border-width is 0.1pt) both -awt and -print
fail to render a border, while -pdf does.
[Separate problem that the borders are in the wrong place
for all renderers..]
The attached sample fo was submitted to this list earlier by
[EMAIL PROTECTED]
' Best,
-Ralph LaChance
-- patch
/**
* draw a filled rectangle in the current color.
* Force 1 pixel wide area if the size rounds to zero.
*
* @param x the x position of left edge in millipoints
* @param y the y position of top edge in millipoints
* @param w the width in millipoints
* @param h the height in millipoints
* @param drawAsOutline true for draw, false for fill
*/
// helper function by aml/rlc to correct integer roundoff problems
//
protected void addRect(int x, int y, int w, int h,
boolean drawAsOutline) {
int startx = (x + 500) / 1000;
int starty = pageHeight - ((y + 500) / 1000);
int endx = (x + w + 500) / 1000;
int endy = pageHeight - ((y + h + 500) / 1000);
if (drawAsOutline)
graphics.drawRect(startx, starty, endx - startx, endy - starty);
else
{
//don't round down to zero
if (w != 0 && endx == startx) endx++;
if (h != 0 && endy == starty) endy++;
graphics.fillRect(startx, starty, endx - startx, endy - starty);
}
}
---
http://www.w3.org/1999/XSL/Format";>Document TitleAlcatelTable of
Contents:1 part title1.1 Part
Title1.1.1 Part Title1.2 Part Title2 part title
p. /
1 part
title
A paragraph.
1.1 Part
Title
This is paragraph.
caption: picture ripped from the
net
1.an
item
2.an itemwith a
break
3.
this item contains another list:
a.an
item
b.an
item
this was the list.
1.1.1 Part Title
This is paragraph. This word is
stressed.
this is
some stressed code.
This is a very stressed
word.
collumn
collumn
collumn
bold collumn
collumn
collumn
caption: a first table
1.2 Part
Title
this is paragraph.
p. /
2 part
title
A very small part.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: tables with margins and borders
Hello Koen I may be able to help with ~part~ of this. The latest version of AWTRender fails to draw a border at all for your .fo file. However, the border re-appears if you increase the border-size to 1.0pt. This may be a (bad) side effect of changes we recently made to the awt render to respect border-size (previously it drew all borders 1 pixel thick regardless of the value of border-size.) My hunch is the thickness calculation is rounding down to zero. [ aside: We will investigate and supply a patch later today if appropriate. The awt renderer should probably render a border one pixel thick when the math rounds to zero. Any comments? ] As for the ~placement~ of the borders, others will need to comment on that. At first glance, it looks to me that the pdf and awt renderers both put the borders in the same wrong place. Which suggests the problem is not in the renderers themselves. One more comment, however, it looks like your table is buried 3 or 4 levels deep in fo:blocks. While that is probably legal, my own experience is that nesting fo:blocks too deeply can lead to spacing and placement problems. As a workaround, you might want to try embedding your table in a single level fo:block -- perhaps that would improve the border placement. ' Best, -Ralph LaChance At 08:19 AM 8/7/01 +0200, you wrote: >Hello, > >I tried it with the snapshot of the night before yesterday (due to the >firewall I cannot get into CVS directly). It was not rendered correctly. > >I have included the document (doc.xml) and the stylesheet (doc2pdf.xsl) >that lead to docxalan.fo > >If rendered to awt few borders are rendered and those rendered are not >aligned with the table. >If rendered to pdf all borders ara rendered but all are not aligned with >the table. > >The version I'm using is from a file called xml-fop_20010806101537.tar.gz >(it is stating FOP 0.19.0-CVS at startup) > >Kind regards, > >Koen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: tables with margins and borders
At 12:44 PM 8/6/01 +0100, you wrote: >I'm using version 0.19.0 from the distribution directory. It seems to have >to the problem both with -awt and -pdf. >I included a snapshot from the awt renderer below. We fixed a few thing regarding border placement in the awt renderer (-awt, -print), although I'm not completely sure this covers what your seeing -- particularly since you report problems in PDF. (I believe everything we did simply fixed things that rendered differently in -awt and -print vs -pdf.) fyi, the awt renderer changes are included in the latest snapshot and will presumably be in 0.20.0 ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Reason for delay
At 02:13 PM 8/6/01 +0200, you wrote:
>Just to give you a hand, I'll try to remember some of the things that have
>been changed (by various people).
here's our $.02 (effective 0.20)
AWTRenders (-awt and -print options)
- eliminated 3D-effect in rendering background color
- borders now draw wider than 1 pixel if appropriate
- fixed a roundoff error in background and border dimension/location
- fixed a positioning error on Top and Right borders
' Best,
-Ralph LaChance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: tables with margins and borders
Koen, Please indicate which version of FOP you are using and which renderer (-awt, -pdf, -print etc) displays this behavior. ' Best, -Ralph LaChance At 11:24 AM 8/6/01 +0100, you wrote: >I'm having some issues with the rendering of table borders. When I ask to >render a border around the table cell's and the table has a left margin of >for example 2cm, than the text is shifted correctly 2 cm to the rigth but >the borders appear disaligned >with the text, ie 2cm to much to the left (I tend to conclude that the >margins are not taken into account when rendering the cell borders). It >looks like a 'bug' to me, as the same file is rendered correctly in the >trial versions of the commericial tools >availlable? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: More table fixes - rendering rectangles
At 11:15 PM 7/20/01 +0200, you wrote: >I'm still slogging away with tables, trying to get eliminate border >drawing errors. I think I've made some progress, both in the table and >in the rendering code. > >I finally discovered why the background rectangles were hanging out a >pixel or so beyond the borders (at least in PDF). When we want to draw a >filled rectangle, we are using the PDF operator which both fills and >strokes the path. Since there is no way to set the stroke width to 0 (0 >means at least 1 device pixel, according to my admittedly ancient PDF >bible), this is drawing a pixel more than the actual size of the >rectangle we are filling. We submitted a patch last week to correct errors in border rendering in AWTRenderer. ' Best, -Ralph LaChance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
proposed changes to AwtRenderer
Change summary org.apache.fop.render.AWTRenderer.java NB: we started from the 5/21/01 version of AWTRenderer.java, which was the latest as of Friday's cvs snapshots. The changes we're submitting, deal with the following 1. Background (colored) areas were being rendered in 3D, which incorrectly applied a bevelled look to the fill. 2. Drawing of lines (e.g., borders) ignored the border thickness and simply drew a 1 pixel line. We've corrected addLine to do the right thing. 3. The actual placement of a couple of the borders were incorrectly computed -- previously hidden by addLine ignoring thickness. This is fixed also. 4. Several places were subject to integer round-off errors, an example is that if you separately colored all the table-cells in a table row the backgrounds would sometimes show white gutters where one would expect the cells to bleed together. The same could happen if you put bottom borders in every cell -- they'd show gaps We realize this AWTRenderer is probably vestigial, in that it doesn't subclass the abstract PrintRenderer, and perhaps is destined for the scrap heap. In the meantime, however, these changes should make its end-of-life happier. At any rate, these changes improve ~our~ product's life. ;-) 'cheers Andy Langowitz [EMAIL PROTECTED] Ralph LaChance [EMAIL PROTECTED] apologies if we stepped on your tabs -- our environment is set to indent 2 cols AwtRenderer.zip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Need Working Sample
At 10:08 AM 7/6/01 -0500, you wrote: Hi, I am new to FOP. I urge you to check the references on the fop web site -- particularly Ch15 of Harold. XML Bible and the two Eisenburg tutorials http://www.xml.com/pub/a/2001/01/17/xsl-fo/index.html ' Best, -Ralph LaChance
