Re: producing arabic pdf
nafise hassani wrote: I look at the arail.ttf.xml file which org.apache.fop.fonts.apps.TTFReader makes it I found that some charachter's unicode does'nt exist in it for example arabic lowercase charachres this leads to showing lowercase chars same as uppercase Characters without a glyph in the font would show as a sharp sign (#). The PDF serializer doesn't substitute characters on its own. J.Pietschmann
Re: producing arabic pdf
[EMAIL PROTECTED] wrote: now i have figure the problem and thats because you are writing from right to left If that's the problem: the PDF serializer has no BIDI support at all: no rl writing direction, no character reordering, no fo:bidi support. This means rendering arabic text is almost out of the question, with the possible exception of snippets with blocks which don't have more than one line and which can be reversed beforehand by some other means (which may be complicated by inline markup and numbers which have to be rendered lr instead of rl). J.Pietschmann
Re: how to list all sitemap components
David Crossley wrote: Geoff Howard wrote: I'd just use eclipse to find every class that implements the right interface(s). Would that work? Thanks Geoff. However, command-line tools only because i need to script it. Sorry, i forgot to specify that. A bit of BCEL should do the trick. J.Pietschmann
Re: help needed (OWQL)
Vadim Gritsenko wrote: Though job. The lazy way would be to use a PipeStream to pipe the content written to the PrintWriter to a SAX parser running in another thread. That's likely to course trouble in some circumstances. I don't see anything lazy about this :) IMHO, lazy way is to use StringWriter and then parse resulting text with SAX parser using one of the Cocoon's Util classes. I always thought I was lazy. But then: running in another thread. That's likely to course trouble ^^ I thought I even spell-checked the message before sending! J.Pietschmann
Re: help needed (OWQL)
Halgurt Mustafa-Ali wrote: I am tryong to itegrate OWQL in to the cocoon framework, I implemented a Transformer for that purpose (see the Attachment please). The OWQL tool has a method printAnswerAsXML (String reqxml, PrintWriter pw) do you have an idea how can I convert pw to SAX events? Though job. The lazy way would be to use a PipeStream to pipe the content written to the PrintWriter to a SAX parser running in another thread. That's likely to course trouble in some circumstances. Another way would be to implement a PrintWriter subclass and an InputSource subclass in order the get the character stream through a parser. NIO char buffers seems to be yet another approach. The most clean way would be to hack the OWQL tool to provide SAX events to the outside world, of course. J.Pietschmann
Re: [OT] Re: formation@anyware-tech.com
Jorg Heymans wrote: On a side note: Thunderbird is not keeping track of threads anymore in the cocoon mailinglists, Works fine with Thunderbird 0.7 on Win2k. You appear to post through GMANE, maybe they have an issue? J.Pietschmann
Re: FOP with embeded SVG doesn't render at correct size in Cocoon
Joerg Heinicke wrote: It's the 0.20.5 release, but built with our Batik 1.5. I guess the FOP people must clarify if this made any sense or not. IIRC we had the released Fop jar in our CVS and got complaints for problems with Batik after Batik update. So we rebuilt Fop with this new Batik and the problems seemed to be gone. Odd. If it compiles, it shouldn't complain about missing methods at run time. There may be behaviour changes though, has someone checked the Batik change log? J.Pietschmann
Re: PDF Encryption
Torsten Curdt wrote: But the way through the user config file seems to fail. Maybe someone else has an idea why? I implemented only setting the renderer options from the CLI. I don't think anybody added setting encryption options (or any other non-font related renderer options beside PDF filters) from the config file. J.Pietschmann
Re: [Help]writing SAX Transformer
roy huang wrote: ... root a a /a b b /b c c /c /root if I delete a b using startRecording the source code turns into: ?xml version=1.0 encoding=utf-8? root c c /c /root left many blank and tab. How to solve it or I am in the wrong way? The whitespace is already there in the source (look carefully). I don't think it hurts, and deleting it selectively is not all that easy. Question 2: in the transformer I also and some xinclude tag,like: attr.addAttribute( http://www.w3.org/2001/XInclude;, href, href, CDATA, flowUri); super.startTransformingElement(, include, xi:include, attr); super.endTransformingElement(, include, xi:include); attr.clear(); the xml is fine,but can't be transform by XInclude transformer, I think you missed the namespace for the xi:include element, but added the href attribute in the namespace instead. Try attr.addAttribute( , href, href, CDATA, flowUri); super.startTransformingElement(http://www.w3.org/2001/XInclude;, include, xi:include, attr); super.endTransformingElement(http://www.w3.org/2001/XInclude;, include, xi:include); instead. Dealing with namespaced elements and attributes in APIs is tricky, study the topic carefully. J.Pietschmann
Re: PDF Encryption
Torsten Curdt wrote: From the FOP documentation I got the impression I could pass them as shown in the wiki. But does that mean these [1] are the only options besides fonts that are currently available? Yes. Without diving into the fop codebase - is it much work to add? How much is much? It would require hacking several files and some reengineering of the tests whether encryption is available which are currently in the CLI class. Given that encryption has several major deficiencies in the maintenance branch code and that the code is to be abandoned anyway, I don't think it will be done. J.Pietschmann
Re: FOP with embeded SVG doesn't render at correct size in Cocoon
Torsten Curdt wrote: Can anyone tell me how the Cocoon fop and batik jar files are generated and how that is different from the jars supplied with FOP? THere were some Cocoon releases which shipped with a different Batik jar than the corresponding FOP release, partly due to interface changes in Batik which forced FOP to use a CVS snapshot. I don't know of the current state, but the latest Batik was released after the latest FOP release, if Cocoon grabbed the latest Batik jar, there are certainly some differences. J.Pietschmann
Re: PDF Encryption
Torsten Curdt wrote: What about a wiki page how you got this working? See http://xml.apache.org/fop/pdfencryption.html for how to set up the infrastructure and the relevant cocoon pages for passing options to the renderer. J.Pietschmann
Re: serialization to jpeg/png error
yangontha Maung wrote: http://myserver:/samples/batik/hello.jpeg I am using cocoon 2.1.3 on Red Hat Linux 9.0; Tomcat 5.0.18. I try to view the samples and when I view svg, it is OK. But when I click the jpeg and png links, there is an error message. The image http://myserver:/samples/batik/hello.jpeg; cannot be displayed, because it contains errors. Standard drill: - Check the Cocoon logs for error messages - Save the file to disk and display in a text editor. Is there palin text at the end? If so, it should contain further hints about the problem. J.Pietschmann
Re: Mail thread headers (was Re: source resolving in 2.2)
Sylvain Wallez wrote: Actually, Unico is not the only one. What I've found is that Mozilla uses the In-Reply-To header whereas Outlook (at least some version) uses Thread-Topic and Thread-Index. Outlook's headers seem strange to me, as I don't know how a mailer can rebuild a thread tree with just an indentifier for the thread, but no information about the posts relationships. *bg* my pet topic... See http://marc.theaimsgroup.com/?l=fop-devm=104335769809427w=2 The Internet Mail Service mentioned there is MS Exchange Server, which actually is the culprit responsible for the Thread-Topic and Thread-Index headers. Even for the Clients sending In-Reply-To and References, there are some caveats: http://bugzilla.mozilla.org/show_bug.cgi?id=191726 The Mail Client sending a bogus Referers header is actually Eudora 5.0 (7.0 is ok). Any ideas where this would fit in the Wiki or somewhere? Perhaps http://nagoya.apache.org/wiki/apachewiki.cgi?ToolChest/Users J.Pietschmann
Re: Saxon as the default XSLT procesor
Nicola Ken Barozzi wrote: But... I swapped Xalan with Saxon 6.5.3 in Forrest and I get a NPE :-( That's not unusual. Did you use the most recent Cocoon? I suppose there are no document() calls in the style sheet, because at least in the Cocoon releases I used it gets passed null as Source quite often for no obvious reason. Xalan tends to ignore this, while Saxon barfs. J.Pietschmann
Re: Saxon as the default XSLT procesor
Nicola Ken Barozzi wrote: document() calls in the style sheet, There are. I'm gonna remove them soon, nut for now they are there, and will the possibility to use them will remain some time for backward compat. because at least in the Cocoon releases I used it gets passed null as Source quite often for no obvious reason. Wierd... I think it's a Cocoon bug. The first invocation of the pipeline is ok, but in followup incovations the XSLT processor often gets a null SourceResolver (not Source, sorry). Xalan uses its own URIResolver in this case, while Saxon (6.x series) takes it literally. That's one of the dark corners of the TrAX spec, I couldn't find any regulations guiding the behaviour. The null is not a MT problem, it happens even for low load. I think it has something to do with incorrect re-initialization of the pipeline after the SourceResolver has been recycled and the reference had been nulled. Given the added problem that document() referenced stuff doesn't influence cache validity, I switched to aggregation. If the document() gets the URI from source XML, this can be painful (XSLT to an XInclude source, then Xinclude, the the final XSLT instead of just one XSLT). The worst thing is that you can't easily test the XSLT any longer with command line tools, even though none of the dynamic features (like cocoon: URIS) are used. If you've to ftp the damn sources to the app server, this really slows down development :-/ . J.Pietschmann
Re: Build failure because of proxy-firewall
Geoff Howard wrote: builderFactory.setAttribute( http://apache.org/xml/features/nonvalidating/load-external-dtd;, new Boolean(false)); Alternatively, try Boolean.FALSE J.Pietschmann
Re: [d'oh!] java APIs are not powerful enough to handle the XML spec!!
Stefano Mazzocchi wrote: The day somebody asks you why java needs to be replaced, one answer will be 'it only supports 16-bits chars'. laughable as it might seem, it's true. yes, people, a Unicode char is not 16 bit (as I always though!) but 32!! This is a misconception. Unicode is an odd mixture: at the same time it defines codepoints for representing characters and surrogate characters for encoding non-baseplane characters (whose codepoints don't fit into 16 bit). ISO 10646 originally intended to use full 32bit for 2^64 characters. Because of slow progress an complaints about wasting space, the Unicode consortium was formed which made quick progress on specifying a 16-bit charcater set. The surrogate characters were built in in case more than 2^16 characters came along, and for giving people plenty of room to experiment themself in the private areas there. Meanwhile, ISO-10646 and Unicode converged: ISO limited the charset to 0x11 characters, which should be enough for everyone, and Unicode dropped the 16 bit charset notation, they just define codepoints. Unfortunately for them, they can't undo the surrogate character mess and other wicked problems they now like to get rid of (singletons, certain compatibility characters, some presentation forms, ligatures). A Java char variable can't hold non-baseplane Unicode charaters, but Java strings can. For Sun JVMs, they are basically a UTF-16 encoded Unicode strings. BTW there are JVMs out there which use UTF-8 in Java Strings, the same way strings are stored in class files. The point is of course: can the run time libraries handle non-baseplane characters? The java.text.BreakIterator can, but that's no magic. I have no idea whether for example AWT display routines can display non- baseplane characters, mainly because I've yet to get an appropriate font. The TTF unicode mapping tables allocate, lo and behold, 16 bits for the character. Who's complaining about Java? BTW Mozilla can't deal with non-baseplane characters either, to the chagrin of the MathML folks who use them for mathematical presentation forms. Guess what's the main reason, beside fonts: C's wchar_t is 16 bit too. now, if you thought you could take the character() SAX event and create a String out of it and do something useful with is (like print it, for example), forget it. The result will very likely not be the one you expect. That's an interesting observation. I never had problems in this area. But this may have something to do with the fact that I never went out of the Unicode baseplane with my chars. Heck, I' Another reason not to use Stings at all. Stings are bad, of course :-) Strings are another matter. In fact, Strings should be preferred over char arrays because they can hide the actual representation of the Unicode strings. If you use character arrays, you have to deal with surrogate character pairs yourseelf. A substring() could be implemented to deal with non-baseplane characters correctly. Of course, Java was invented when people thought of Unicode as 16 bit charset, and the standardized behaviour is that the String methods operate on the internal char array. J.Pietschmann
Re: Random comments and bugfixes
Stefano Mazzocchi wrote: ... 0xd800 is not a legal XML character. ... high-unicode ...#65536;/high-unicode Now: whose problem is this Slide's or JDOM's? JDOM, I'd guess without looking at the code. This is a very general problem: The surrogate Unicode codepoints are illegal for itself in XML, but of course in Java strings there is no way to express non-baseplane characters other than as two surrogates. Problem: if the test for illegal surrogates is before character reference expansion, illegal surrogates may sneak in as char refs. If the test is after character reference expansion, a non-baseplane character may trigger a false positive. Obviously, the test has to be done twice, once for literal characters and once as part of dealing with character references. I personally wouldn't loose much sleep over this particular problem. Unless you are into MathML or obscure historic scripts, non-baseplane characters are more of a curiosum. J.Pietschmann
Re: Random comments and bugfixes
Sylvain Wallez wrote: Ermm... not that I will loose sleep, but what is a baseplane character A sloppy phrase :-) The Unicode base plane covers the code points U+..U+, i.e. characters which can be represented using a 16 bit value. There are characters assigned to code points above 65536. Check http://www.unicode.org for details. J.Pietschmann
Re: DO NOT REPLY [Bug 23299] - [PATCH] UTFDataFormatException: String cannot be longer than 32k.
Joerg Heinicke wrote: ?? Who should fix it that it works like expected, i.e. one text node in one p element? XSLT processors generally hide the issue, whether by normalizing the input while or after the tree is built or by other means. The interesting stuff of course are XPath processors working on potentially unnormalized DOM structures, in particular Cocoons XInclude processor and the XPath transformer. I'd say you'll get all kind of interesting behaviour. J.Pietschmann
Re: HTML editor widget (was Re: [proposal] Doco)
Bruno Dumon wrote: I've only just started with some little javascript experiments, so it's not like any code has been written yet. You can look at http://bitfluxeditor.org/ for a start. * support for both Mozilla and IE is important. That's going to give one or two headaches more :-) J.Pietschmann
Re: [vote] Changing the mime type setting of a reader [was [RT]...]
Joerg Heinicke wrote: No one really missed it until now This isn't quite correct. :-) However, it isn't actually a really incompatible change, at least for the provided Reader classes, it just adds a feature. J.Pietschmann
[humor] New idea for Cocoon block
http://www.bbspot.com/News/2003/10/techno_babble.html Wouldn't this be a great enhancement for the Cocoon website? :-) J.Pietschmann
Re: [RT] Starting 2.2
Timothy Larson wrote: I also wondered about Subversion when the repositories started multiplying :) Is this a possibility? Is there a good CVS-Subversion repository converter? What's good? The Subversion project has a converter, last time I checked they said it still can't convert branches, and that this was *the* killer for declaring SVN to be production ready. Trunk only CVS repositories seem to work for a long time already (disclaimer: gathered from various messages, I didn't try personally). J.Pietschmann
Possible Wiki vandalism
Hi, could someone have a look at http://wiki.cocoondev.org/Wiki.jsp?page=UnusedPages and perhaps clean up, just in case this wasn't intended... J.Pietschmann
Re: [RT] the value of being wrong
Stefano Mazzocchi wrote: Or, if you want to rephrase, ... the communitytator? J.Pietschmann
Re: [RT] Adaptive Caching
Berin Loritsch wrote:
Speaking of accademic, anyone have a Java implementation of tanh(x)? The
java.lang.Math class only has tan(x) or atan(x), but no hyperbolic
function.
Trivial, see
http://functions.wolfram.com/ElementaryFunctions/Tanh/02/
(yeah, wolfram research is for mathematics on the net what
wikipedia is for the rest)
double tanh(double x) {
return (Math.exp(x)-Math.exp(-x))/(Math.exp(x)+Math.exp(-x));
}
Have fun!
J.Pietschmann
