RE: selected checkbox
I haven't followed this thread at all, however it occurs to me that you can get a Graphics object from Batik (can't you?), draw into it using the java.awt.Graphics API, and then output that as SVG. So couldn't you create a JCheckBox and paint it to an SVG Graphics() ? Maybe I'm talking rubbish but I thought this was possible. M. On Thu, 2001-12-20 at 09:35, Conal Tuohy wrote: -Original Message- From: Cyril Rognon [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 19 December 2001 21:34 To: FOP dev Subject: RE: selected checkbox Do you have any svg code for a checkbox (checed and un checked version) ? or some pointer where I could find some ? something like this? !-- an unchecked checkbox -- svg width=10mm height=10mm rect x=0 y=0 width=10mm height=10mm style=stroke:rgb(0,0,0);stroke-width:1;fill:none/ /svg !-- a checked checkbox -- svg width=10mm height=10mm rect x=0 y=0 width=10mm height=10mm style=stroke:rgb(0,0,0);stroke-width:1;fill:none/ line x1=2mm y1=2mm x2=8mm y2=8mm style=fill:none;stroke:rgb(0,0,0);stroke-width:2/ line x1=8mm y1=2mm x2=2mm y2=8mm style=fill:none;stroke:rgb(0,0,0);stroke-width:2/ /svg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] msg04345/pgp0.pgp Description: PGP signature
Re: OT(?): transcendental functions in XSLT
Howdy transformers,
Thanks to those that helped me out. I tried the developerworks article
that Trevor mentioned; the article was for an older version of xalan,
but once I knew where to look I was able to bind to the java.lang.Math
class and now I have transcendentals coming out my ears :)
Anyway I got one wedge of pie to draw now, and a second one draws OK for
areas 50%, so I'm on my way, I'll put the scripts on my web site if I
get them working satisfactorally.
Cheers
Mark
On Tue, 2001-09-18 at 01:40, Wim Beliën wrote:
If you are using xalan, you can add the
xmlns:math=xalan://java.lang.Math namespace
to your xsl document. Then you can use all
methods out of the java.lang.Math object.
like
line x1={math:log(myTag)} y1=0 x2={math:log(myTag)} y2=0/
Although I haven't tried, I think this should also be possible in a svg
path construction like
path d=M275,175 v-150 a150,150 0 0,0 -{150 * math:sin(myTag)},{150 -
math:sin(myTag)}z
fill=yellow stroke=blue stroke-width=5 /
Please keep me posted of your results.
++
Wim Beliën
Netherlands Institute of Applied Geoscience TNO
Delft, the Netherlands
tel : +31 15 2696824
email : [EMAIL PROTECTED]
++
- Original Message -
From: Mark [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, September 16, 2001 5:28 PM
Subject: OT(?): transcendental functions in XSLT
Hi folks,
sorry for this slightly off topic post but i was hoping someone could
help me.
I thought i should be able to produce a very simple xml schema for
generating pie charts. the idea was that I could use XSLT to transform
from the pie-chart schema to SVG (and then to import the SVG into FOP).
It would be preferable to express the size of the pie chart segments as
percentages, but the SVG Path object requires coordinates on the
circumferance of a circle.
The problem is that there don't seem to be any functions in XSLT or
XPath that let me find the sin() or cosine() of an angle. Am I missing
something? I thought I could possibly use a transform but I can't seem
to perform a transform in the middle of a Path.
I finally decided that maybe if I created a table of degree-to-sin/cos
mappings I could somehow use the document() function to import this into
the stylesheet and use an index to search it (ergh) but that doesn't
seem to work either.
There's little point in having a pie-chart schema if you have to do the
calculations yourself anyway.
So if anyone has any suggestions .. ? I'd certainly be pleased to share
a pie-chart-XSLT transform if I can get it going.
As an aside, does anyone know why SVG paths are so (IMHO) brain dead? I
can't believe that the elements in a path aren't XML elements, it seems
very strange. (Generating the paths in XSLT is going to be a bit
painful, even if I can get the sin() of an angle. I dont really see how
M300,200 h-150 a150,150 0 1,0 150,-150 z qualifies as XML).
Cheers
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
PGP signature
Re: FAQ: Where's the Windows zip file for Fop?
Why not stick the whole distro into a JAR file? Everyone has jar, don't they? (and aren't JAR and ZIP files compatible with each other?). Maybe this is a dumb idea but it seems a bit silly to have platform wars when there's a Java standard for archiving. I'm not really sure why we don't see this used in more places, but maybe that's why it's a dumb idea :) Mark p.s. im back! :) Weiqi Gao wrote: On 28 Aug 2001 15:55:38 +1000, Peter B. West wrote: How about a Fop-0.20.1-bin.zip.txt, explaining how to unzip a tar.gz? It might reduce the F of this AQ. Q: Why isn't there a Windows .zip version of Fop on the download site? A: To save diskspace on the Fop download site. This is practical for two reasons: 1. For a Java project, the zip archive and the tar.gz archive would contain exactly the same content. So one of the two is superfluous if each format can be unarchived on every platform that mattered. 2. It is indeed the case that each format can be unarchived on every platform that mattered. One can easily unzip an zip archive on Linux, thanks to the GNU zip/unzip programs. One can also gunzip and untar a tar.gz archive on Windows, thanks to the GNU tar program and Cygwin (or WinZip, or even PKZIP, if one is so inclined). Since tar.gz archives is always smaller than zip archives, (at least for archives the size of the Fop project), it is natural to choose tar.gz as the only archive format on the Fop download site. This format causes little to no problems for the various UNIX platforms. Some UNIX flavor's tar command is incompatible with the GNU tar command for pathnames longer than 100 characters. The problem is easily remedied by downloading GNU tar from http://www.gnu.org/software/tar . For Windows NT/2000/etc. platforms, just drag the tar.gz archive and drop it into the WinZip (http://www.winzip.com, $29) or PKZIP for Windows (http://www.pkware.com, $29) window. A better solution would be to download the free software Cygwin (http://cygwin.com) and get the GNU tar program as part of the suite. Cygwin is free software in the genuine FSF sense. The suite you download will include not only GNU tar, but also many of the other GNU utilities (bash, gcc, etc.). The command line syntax of GNU tar is very similar the the JDK's jar command. To unarchive Fop-0.20.1-bin.tar.gz, for example, one runs: tar zxvf Fop-0.20.1-bin.tar.gz [I don't use MacOS, but surely there must be a port of GNU tar for it, right?] (Until this is either added to the web site, or the FAQ, we can always point to the mail archive for new zip archive queries.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Attracting companies to FOP (was: Re: Public API Change in Driver)
Hi fopsians, Arved sed, I think that OS practise is proving out that largish projects (and FOP is a largish project) need a core team of at least 2 or 3 FT developers to provide momentum, continuity, and a rallying point. FOP doesn't have that, although long-time developers and committers try their best. So we are hurting because of it. I could be wrong but I don't think I am. So any suggestions from outside the FOP circle are welcome. FOP and the technology it represents, and the number of other Apache projects that it could augment or cooperate with, is a big deal, IMO. It is worth some higher-level attention and thought, I think. To my mind the primary issue with FOP's development is actually an issue with XML:FO in general, and that is that it's usefulness and the range of problems it solves have not really been well enumerated. Unless you know what problems are solved by a solution then it's hard to get excited about it. I agree that FOP is a Big Deal but not that it's Obviously a Big Deal. I mean, maybe people are evangelising XML:FO but I don't think it's been effective, because I had to work it all out on my own. I don't mean to say that it's hard to work out, just that I think that part of the appeal of things like XML or Linux is their obviousness: a standard, human-readable encoding for all structured data and a free modern operating system, versus ... this thing, right, where you take these bits, see, and then you take these other things, and then you replace this CSS thing, right, and well, you have a web browser, right, and ... My point is that whenever I read about XSL:FO I see how it's going to make reading stuff in our browsers much nicer, and how it replaces CSS. Well, noone's going to get too excited about that, because Microsoft and to a lesser extent AOL/Netscape/Mozilla are driving the market there and XSL:FO may or may not make an impact - it's really not in our hands. But XSL has implications that far exceed web pages and CSS replacement. I don't see this spoken of much. XSL is potentially an excellent way to produce paper reports, to do graphing (with SVG), to do excellent page layout for non-web applications, and to generally enhance or standardise the end-products (human readable outputs) of just about any software. It means we can get rid of all these proprietary reporting systems and replace them with standard, free ones -- at least in theory. I'm just ranting about this because I think that there needs to be a compelling reason why someone like IBM might take on the task of helping with something like FOP. As a HTML replacement, it's a big yawn. As a way of producing all those thousands of tonnes of paper reports that get printed out every day by big-iron machines, maybe it's a bit more exciting, maybe people could see where it could help the bottom line? I know that projects like Linux and Apache didn't really get much support until they were well into the 1.0+ stages of their lives. So it seems to me that battling forward to 1.0 and a big splashy press release would be the start of getting some 'real' sponsorship of the project. I know that 1.0 is a goal and I don't mean to imply that I think it's taking too long (I don't). I'm just saying that 1.0 seems to me to be a very important step for more reasons than just completing the spec. Also, some 'live' examples of real-world stuff on the FOP page would be good, some enumeration of the benefits of XML:FO and FOP, some ways that FO can be applied to solve real problems. Certainly I can help with examples of that, since I got involved in this project specifically because of the advantages of FOP over other mechanisms for producing output. I'm just saying it how I see it, of course; maybe I'm oversimplifying and talking out my botty. But the FOP page doesn't really get me all worked up about how it's going to change the world, even though I'm pretty sure it's impact will be huge. So I guess I'm saying it's a marketing problem...? Cheers Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Public API Change in Driver (Was Re: [GUMP] Build Failure - Cocoon2)
FOP underwent some major refactoring to massively reduce memory usage, and it might not be possible to make a workable deprecated API for backwards compatibility. (Mark?) We don't break API compatibility lightly, and don't expect to have to do so again in the foreseeable future. Sorry for not posting to Cocoon-dev earlier what was up. I remember wishing that I didn't have to make the API changes because, well, public API changes are bad, ok? But in the end it was necessary because the old API implicitly assumes that the FO tree building is separate from the formatting/rendering, which is no longer the case. I can't imagine how one would write a compatability layer. (As an aside I will be away on holidays from Sunday - thankfully out of the reach of my laptop (unless someone posts it to a small island in thailand ;). So if anyone has questions/comments/abuse then you'll have to wait till I get back. :-) Cheers Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
FOP jar and patches available
Hey Fopstars I've finally managed to post my diffs, JARs, tars and output samples, along with a fairly lengthy explanation of what I've done, to the web. This includes a PDF bug fix so that Acrobat should work again, now. Check it all out at: http://www.inomial.com/fop Let me know if any links are dead or you have any problems. Instructions to applying the patch are on the web pages. The source and JARs are against the current CVS, updated only minutes before I sent this email. Note that I use Unix (Linux) so I don't know how patch/diffs/cvs/etc work on That Other Operating System. Feedback is definitely welcome, updates and patches etc likewise. All modified files are commented. Regards Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP in a servlet under load
Hi With my changes to FOP I can process tens of thousands of pages of XML:FO in only a few Mb of heap. I have asked for testers but so far noone has responded... this sounds like an ideal environment in which to test, no? The performance of FOP seems also to have improved, probably because the GC is a lot less stressful (far fewer objects to scan and far fewer OS memory requests being performed). I hope to have my final changes completed today at which time I will post a summary of them and submit them for inclusion... they are not too major. I have modified all of the renderers to suit and have a slightly different API and calling sequence. But I'm happy to send a JAR and the sources to anyone who wants them earlier. One of the main problems with FOP IMHO is not that it is poorly designed but that there has been little control over the quality of the code that is present there. There are wild variations in the code, assumptions made in it, commenting, use of public/private members, coupling, cohesion, maturity, you name it and it changes from file to file and module to module. I make this observation because a redesign of FOP is not going to make these issues go away - another solution is required. I'll look at the synchronization issues once I'm finished with the pipelining issues, assuming my patches are worthwhile :) Regards Mark Weiqi Gao wrote: We did some playing around with a simple FOP servlet that does XHTML-XSL-FO-PDF using Xalan and FOP and come away with the following findings: 1. It uses quite a bit of memory. While running around 20-30 concurrent users, each generating a set of four PDFs ranging from 2 to 5 pages five times each, the servlet engine memory usage is about 110MB. 2. It uses quite a bit of CPU. While running the above test, the CPU is about 50% with 10 users, 70% with 20 users, and over 80% with 30 users. 3. It takes quite a bit of time to do the generation. The minimum generation time for the four documents are from 1 to 4 seconds (the 4 seconds one is 5 pages with 13 tables with various cell colors and border styles). In the 30 user test, the average time are from 20 to 40 seconds, and maximum well over 2 minutes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP in a servlet under load
I just run 30 threads of my earlier chapter 15 allelements example on my home machine and noticed that compared to a single thread run, time spent on XSLT increased roughly 6 fold, time spent on build FO tree increased 30 fold, formating 12 fold. Context switches are at 6 per second level while in FOP, compared to 4000 per second while in Xalan. In unmodified FOP, input from the source FO document occurs entirely at the beginning of the FOP run, and output entirely at the end. Therefore, the largest part of FOP processing occurs entirely in-memory and is therefore CPU bound. If you run 30 CPU bound threads concurrently on a machine with less than 30 CPUs then you are going to get degraded performance. When you say 6, 30 and 12 fold, I assume you mean times? AFAIK, processing time on a single CPU machine with a CPU bound thread running with 29 other concurrent CPU bound threads *should* take 30 times longer, because it's executing 30x the instructions. If the XSLT and the formatting are doing I/O then these parts of the system will benefit from threading because the JVM can make progress during IO waits. I'm actually surprised that the numbers aren't much higher, but perhaps you have SMP. Anyway, I'm not sure if my analysis is entirely correct here but none of this seems particularly surprising to me, and doesn't indicate any problems with FOP processing per se. Of course there is a lot I don't know about FOP so maybe someone call explain this to me. Regards Mark The data seem to point to contention problems as was pointed out yesterday. It might be instructive to construct a similar applet that uses Xalan to do XHTML-XSL-FO, and serve those FOs (labeled as application/xml) to the browser. If a significant portion of the load is due to Xalan, a reduction might be possible by using a different XSLT engine such as SAXON. (SAXON is also more compliant than Xalan.) -Chris -- Christopher R. Maden, XML Consultant DTDs/schemas - conversion - ebooks - publishing - Web - B2B - training URL: http://crism.maden.org/consulting/ PGP Fingerprint: BBA6 4085 DED0 E176 D6D4 5DFC AC52 F825 AFEC 58DA - 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: FOP in a servlet under load
Hi, You can certainly fire them over to me - I'll be happy to test. Great! Thanks. I'm just about ready to send you a bunch of stuff, I think. Have worked out the citations business and will ask you a few questions privately if that's OK. Well, yeah, you're right. Rather than comment on this further right now, because I want to crash out, let's just agree that redesign is another issue entirely (in fact we really do need one, I believe), and that reformatting is just a stopgap - it doesn't address the issues you mention. Over the next couple of weeks we'll obviously have to hash this out. OK. I think my concern here grows from the fact that (a) I'm new and (b) the comments I've seen recently about redesign have not, to me, been design issues. Also, I want to say that I was not complaining about the code quality as such - in a project like this just about all code is Good Code and it's important to be grateful for and gracious about it - but just that the quality variability can itself cause problems. The design is still holding its own (you'd have to read the archives to get a feel for why we want to move on, but all that discussion pertains to a FOP 2), but one real problem is the lack of design documentation - docs diagrams. Another real problem is that we are operating sort of at a CMM Level 1 - the project is succeeding because of individuals and not because of process. All stuff we need to talk about, definitely. Yeah, but I suspect an open source project can never get much past CMM 1 by it's very nature. I like the idea of the CMM categories but I think that in practise CMM can't solve problems for a bunch of autonomous people who don't even share a time zone. But there is probably going to be a better time than the present to talk about that sort of thing. :-) Cheers Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP in a servlet under load
Hi Weiqi, In unmodified FOP, input from the source FO document occurs entirely at the beginning of the FOP run, and output entirely at the end. Therefore, the largest part of FOP processing occurs entirely in-memory and is therefore CPU bound. If you run 30 CPU bound threads concurrently on a machine with less than 30 CPUs then you are going to get degraded performance. That's exactly what we observed. Unfortunately, in the servlet world, multi-threading is the norm. Not so much to distribute the load as to handle concurrent requests. I simply cannot queue up all the requests and process then one at a time. Why not? It would be pretty easy to make a queue up that processes FOP objects serially, blocking the servlet thread until the requested object is formatted. With a centralised Queue you could then select the number of FOP processors that are processing the entries on the queue. I have a nice multithreaded Queue implementation that allows multiple servers on a single queue with multiple submitters - it doesn't block the enqueue caller, but that wouldn't be too difficult. That way you can have the right number of threads for the number of CPUs you have, and you should get better overall performance and much less memory usage. Sure, the servlet thread(s) will block waiting for processing, but that's what happens anyway, right? I am actually interested in solving this problem because I am using XSLT-XHTML in servlets, but I am using a HTML serializer rather than FOP to output to browsers. The question then becomes, is there room for improvements. From what I've heard so far, the answer is yes. Replacing inefficient JDK 1.1 always synchronized data structures, streamline the processing model, find ways to reduce object creation and garbage collection, seems to be the key. Agreed, there are plenty of places to improve FOP, definitely in the current implementation but also (apparently) in the design. I've just finished (I hope!) the first of a couple of iterations that should improve the throughput and memory use of FOP significantly. I hope to send patches and JARs out in a few hours, but there are plenty of places where things could be improved. Just one example is the FONode which always allocates a Vector, even if it has no children... there are plenty of these things - but that's OK. It's much more important to get things broadly correct than to be totally optimised, especially at this early stage. When you say 6, 30 and 12 fold, I assume you mean times? Yes. But I have to prefix that with 'uncontrolled unscientific unofficial pseudo-benchmark on a home machine'. Don't read too much into it. Sure, I wasn't reading too much into it, just replying. But a 30-fold time increase from 2 seconds is about 34 years. :-) I'm just a pedant I think, everyone these days seems to say fold when they mean times. It's like saying one could care less when one actually couldn't. :-) Following suggestions from another post in the thread, we tried Saxon in place of Xalan, and achieved noticeable speedups. And yes, Saxon is picky! I'll share some numbers later. Great! It raises a question about the suitability of using FOP in a servlet environment. We certainly learned what is and is not achievable with today's FOP. And we'll regulate its use in a way that won't flatline the servers. I believe that there are going to be processing speed limitations in FOP, and (IMO) XML in general, for the next while. For example, most software (including FOP, I think) seems to process XML by comparisons with tags, lookups in dictionaries, etc etc. While this is lovely, what we end up with is this whole chain of inefficient processing - from XSL to FO to PDF - where everything is dealt with as Strings, with the management and resource usage that entails (regardless of language). It would be ideal if, for example, an XSLT processor could say to FOP, OK, instead of sending you the string 'fo:block', I'm going to send you the integer 1 - this double-handling of everything slows XML processing down significantly, and this means that there are going to limitations on how fast it's possible to make FOP go. In reality, I reckon that XML needs to be preprocessed before computers get to it, kinda like using lex before sending stuff off to yacc. But rather than whinge I should just do something about it in my spare time :-) Anyway, all of the above are just the demented ramblings of someone who wishes that there was a way of efficiently encoding XML documents for processing. I love XML, but to summarize, I think FOP's problem is largely XML, not FOP. I'll volunteer to test. Email me at [EMAIL PROTECTED] Great. I'm going to have a look at another phase of optimisation before I send you something because I suspect that all the renderers are working a particular way and, if so, then I may as well take advantage of it now - which will reduce the memory footprint even more, if
Fop flop?
Hi foppers I just checked out the latest fop from CVS (after a long hiatus). After building it I get the attached messages when I try to run it against an input file that works under the version of FOP I downloaded from the web page today. I suspect this is a problem with the CVS FOP but I'm not 100% sure, can anyone help me? Is the CVS FOP currently working? One point is that the padding- referred to in the error message does not exist in my (extremely simple, but very large) input file. Also I was wondering about the status of the large document (memory related) patches that I think were submitted a few weeks ago (since this is what I would like to look at/work on). Can anyone tell me if they have been committed yet, or if they will be committed, or if I am asking too many questions? :-) My thanks of a general kind to the developers, Cheers Mark [mark@spiffy xml-fop]$ java -jar build/fop.jar /tmp/bigfile.fo /tmp/bigfile.pdf FOP 0.19.0-CVS using SAX parser org.apache.xerces.parsers.SAXParser building formatting object tree setting up fonts formatting FOs into areas [1WARNING: no Maker for padding- WARNING: property padding- ignored WARNING: no Maker for padding- WARNING: no Maker for padding- WARNING: property padding- ignored WARNING: no Maker for padding- WARNING: no Maker for padding- WARNING: property padding- ignored WARNING: no Maker for padding- WARNING: no Maker for padding- WARNING: property padding- ignored WARNING: no Maker for padding- WARNING: property padding- ignored ERROR: null [mark@spiffy xml-fop]$ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
