Re: Unix and FOP ?
On Friday 12 April 2002 22:43, you wrote: yep The only area that Windows is (arguably) superior to Unix is in Graphics and especially FONTS. A consequence of Windows success is the fact that almost all computers have Windows licenses. This lets us use the Windows fonts. You need to have the Windows license however. The Windows license doesn't require that you actually run all of Windows. So in using the fonts, we are using Windows as licensed. We are just ignoring the unreliable parts of Windows (generally the executabe parts). Now actually installing and using the Windows fonts is an area which needs better documentation. in userconfig.xml, but Can I use the specials fonts by Window without problems into UNIX.? That's possible? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[GUMP] Build Failure - xml-fop
This email is autogenerated from the output from: http://jakarta.apache.org/builds/gump/2002-04-13/xml-fop.html Buildfile: build.xml init-avail: init-filters-xalan2: [copy] Copying 1 file to /home/rubys/jakarta/xml-fop/build/src/codegen init: [echo] --- Fop 1.0dev [1999-2002] prepare: [echo] Preparing the build directories [mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/fo/properties [mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts [mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/svg [mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/classes/conf [mkdir] Created dir: /home/rubys/jakarta/xml-fop/build/classes/hyph [copy] Copying 3 files to /home/rubys/jakarta/xml-fop/build/classes/conf codegen: [echo] Resetting codegen directory [copy] Copying 30 files to /home/rubys/jakarta/xml-fop/build/src/codegen [echo] Generating the java files from xml resources [style] Processing /home/rubys/jakarta/xml-fop/build/src/codegen/allprops.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/fo/properties/Constants.java [style] Loading stylesheet /home/rubys/jakarta/xml-fop/build/src/codegen/genconst.xsl [style] Processing /home/rubys/jakarta/xml-fop/build/src/codegen/foproperties.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/fo/properties/fo_ignore_this.java [style] Loading stylesheet /home/rubys/jakarta/xml-fop/build/src/codegen/properties.xsl [style] Processing /home/rubys/jakarta/xml-fop/build/src/codegen/foproperties.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/fo/properties/FOPropertyMapping.java [style] Loading stylesheet /home/rubys/jakarta/xml-fop/build/src/codegen/propmap.xsl [style] Processing /home/rubys/jakarta/xml-fop/build/src/codegen/foproperties.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/fo/properties/foenums_ignore_this.java [style] Loading stylesheet /home/rubys/jakarta/xml-fop/build/src/codegen/enumgen.xsl [style] Processing /home/rubys/jakarta/xml-fop/build/src/codegen/charlist.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/CodePointMapping.java [style] Loading stylesheet /home/rubys/jakarta/xml-fop/build/src/codegen/code-point-mapping.xsl [style] Transforming into /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/CourierBold.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/CourierBold.java [style] Loading stylesheet /home/rubys/jakarta/xml-fop/build/src/codegen/font-file.xsl [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/Courier.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/Courier.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/CourierBoldOblique.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/CourierBoldOblique.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/CourierOblique.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/CourierOblique.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/Helvetica.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/Helvetica.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/HelveticaBold.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/HelveticaBold.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/HelveticaBoldOblique.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/HelveticaBoldOblique.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/HelveticaOblique.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/HelveticaOblique.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/Symbol.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/Symbol.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/TimesBold.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/TimesBold.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/TimesBoldItalic.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/TimesBoldItalic.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/TimesItalic.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/TimesItalic.java [style] Processing /home/rubys/jakarta/xml-fop/src/codegen/TimesRoman.xml to /home/rubys/jakarta/xml-fop/build/src/org/apache/fop/render/pdf/fonts/TimesRoman.java [style] Processing
Re: Non rendered characters in and around fo:inline tags at pagebreak
Nicolas Mazziotta wrote: When a fo:inline element occurs at page break, its text() happens not to be rendered.. What can I do? You can post a small FO file demonstrating the problem to the list. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: Multithreading FOP ?
Folks, Please indulge my ignorance again. May I assume that it is not possible to run two main()s in the same VM? From this discussion so far I have gained much more insight into the nervousness about statics. Is the problem that servers want to execute multiple instances of classes within the one VM? Are there other problems? Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: AW: Multithreading FOP ?
Peter B. West wrote: Please indulge my ignorance again. May I assume that it is not possible to run two main()s in the same VM? Not in the sense you probably mean. From this discussion so far I have gained much more insight into the nervousness about statics. Is the problem that servers want to execute multiple instances of classes within the one VM? Are there other problems? The problem is multiple threads accessing static class data, which is really global. Well, the standard scenario is: There are multiple threads sleeping while waiting for requests. One thread wakes up, sets the FOP baseDir, creates a Driver instqance and starts rendering. Just before the thread is about to resolve an URI for an external graphic, it is suspended and another thread gets a chance to run, it reads its request, sets the global baseDir to soemthing else, and is itself suspended in favour for the first thread, which reads the now changed value for baseDir from the configuration, and explodes. It doesn't help to make the Driver methods synchronized, because there are two instances of the driver object :-( you would have to lock the global configuration data so that the second thread would have to wait until the first finishes processing. Of course, this nullifies the advantages of using multithreading, especially on MP machines. I like the approach JAXP did for transformers. You have a factory where you can set default stuff so that you don't have to do this every time an individual processor is created, and you can override settings on the individual instances. The individual processor instances never access global data after creation. Does this answer your question(s)? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8050] New: - Soft hyphen (shy;) is not handled properly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8050. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8050 Soft hyphen (shy;) is not handled properly Summary: Soft hyphen (shy;) is not handled properly Product: Fop Version: 0.20.3 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Soft hyphen (shy;) is not handled properly. A hyphen always appears, even if no line break has been inserted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Vote] New committer: Jeremias Maerki
Hi all, I would like to propose Jeremias Maerki as a new committert for Fop. Jeremias has already contibuted the PS Renderer and quite a few bugfixes/patches, helped to improve the documentation and is very helpful on the mailing lists. Here is my vote: +1 Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Vote] New committer: Jeremias Maerki
Agreed, definitely. +1. I think we want to be generous when proposing and voting on new committers. The main thing is staying power - I can say this even though my efforts have been sparse as of late - and all three nominated individuals have demonstrated plenty of it, to my mind. AHS -Original Message- From: Christian Geisert [mailto:[EMAIL PROTECTED]] Sent: April 13, 2002 3:04 PM To: [EMAIL PROTECTED] Subject: [Vote] New committer: Jeremias Maerki Hi all, I would like to propose Jeremias Maerki as a new committert for Fop. Jeremias has already contibuted the PS Renderer and quite a few bugfixes/patches, helped to improve the documentation and is very helpful on the mailing lists. Here is my vote: +1 Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Fop with Cocoa Obj-C with Java
I am Fopping now, embedded in an MacOS X Cocoa Application. I am so happy. I will share it with you if you like. I had to write a Cocoa System Service in Java. Took me a while to understand the Apple documentation. The service got rid of Cocoa event problem because of the AWT usage in Fop Source. I could not find a sample of a Cocoa System Service written in Java. So I do not know if I did it correctly, but, it is hard to argue with something that works. If any fop-dev folks want me to make it an example let me know if I should. In the Apache.org Xerces-C they make a Projects directory in the distribution source with directories for the various operating systems. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fop with Cocoa Obj-C with Java
Hey Rich: I could sure use one. I've been playing with Cocoa myself, and facing some similar issues in terms of the somewhat abbreviated (to say the least) Apple documentation. Thanks! jw Rich Van Deren (???) wrote: I am Fopping now, embedded in an MacOS X Cocoa Application. I am so happy. I will share it with you if you like. I had to write a Cocoa System Service in Java. Took me a while to understand the Apple documentation. The service got rid of Cocoa event problem because of the AWT usage in Fop Source. I could not find a sample of a Cocoa System Service written in Java. So I do not know if I did it correctly, but, it is hard to argue with something that works. If any fop-dev folks want me to make it an example let me know if I should. In the Apache.org Xerces-C they make a Projects directory in the distribution source with directories for the various operating systems. - 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: AW: Multithreading FOP ?
Joerg,
Thanks, it does answer my questions, and raises a few others. I'm
heartened by this, because what you have described is the inappropriate
use of global data in a multi-threaded context. I'm interested because
I like statics. They are smaller and faster; what's not to like?
Before continuing with them, though, I need to make sure that I
understand the problems.
The scenario you describe is a doomed attempt to globalise local data.
However, there are times when some initialization of truly global data
is required, yet it cannot be accomplished with static{} blocks. What's
needed is a one-time initialization method. This can be synchronized.
Protect the initialization method or some initialization object, and
set a flag within the method to declare that the job is done. Test this
on entry, after synchronization. Because none of the processes which
require the data will attempt access until after init, access itself
does not need to be synchronized. (I'm assuming here that all statics
are global relative to the JVM.)
It seems to me, of what I have heard so far, that there is no problem
with statics _per se_. If they are used with an awareness of the
possibility of multi-threading, they should present no special
difficulties. I have heard it said, though, that statics are forbidden
in EJB environments. Is this true? If so, what are the special
constraints that apply to EJBs?
Regarding configuration in FOP, it is interesting to note that there are
two different config hierarchies depending on whether the environment is
uniform, as, e.g., in a single thread, or diverse, as in the example
Arnd offered. (That is, a separate process constructs stylesheet
information and other variables into an instance-specific storage
location, and invokes a fop thread with a reference to that location.)
In the first case, the config hierarchy is:
system config
user config
command line
despite the fact that the user config file may be specified on the
command line. Other data from the command line will override
assignments in the user config (else why specify them?)
In the second scenario, the most instance-specific data is in the user
config file (if that is being used to pass the instance data) or in some
other instance-specific config source. So the hierarchy looks like:
system config
command line
user config
or
system config
user config
command line
instance config
I like the second idea better.
Not knowing a great deal about JVMs and class loaders, I'm curious to
know how dynamic data can be introduced into threads started within a
pre-existing JVM. One solution of Arnd's problem would seem to be to
control the process of setting up the FOP thread configuration
subdirectories from within the JVM, and allow for new FOP objects to be
initialised with this information. That is not a general solution ot
the problem though. How is it usually done?
Peter
J.Pietschmann wrote:
The problem is multiple threads accessing static class data,
which is really global.
Well, the standard scenario is: There are multiple threads
sleeping while waiting for requests. One thread wakes up,
sets the FOP baseDir, creates a Driver instqance and starts
rendering. Just before the thread is about to resolve an URI
for an external graphic, it is suspended and another thread
gets a chance to run, it reads its request, sets the global
baseDir to soemthing else, and is itself suspended in favour
for the first thread, which reads the now changed value for
baseDir from the configuration, and explodes.
It doesn't help to make the Driver methods synchronized,
because there are two instances of the driver object :-(
you would have to lock the global configuration data so
that the second thread would have to wait until the first
finishes processing. Of course, this nullifies the advantages
of using multithreading, especially on MP machines.
I like the approach JAXP did for transformers. You have
a factory where you can set default stuff so that you
don't have to do this every time an individual processor
is created, and you can override settings on the individual
instances. The individual processor instances never access
global data after creation.
Does this answer your question(s)?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: AW: Multithreading FOP ?
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED]] Sent: April 13, 2002 11:15 PM To: [EMAIL PROTECTED] Subject: Re: AW: Multithreading FOP ? [ SNIP ] It seems to me, of what I have heard so far, that there is no problem with statics _per se_. If they are used with an awareness of the possibility of multi-threading, they should present no special difficulties. I have heard it said, though, that statics are forbidden in EJB environments. Is this true? If so, what are the special constraints that apply to EJBs? Being distributed is the major factor. This is also true for servlets that are J2EE-compatible. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
