Antwort: Re: Antwort: Re: Changing logging behavior in an embedded application.
i could do something like this: Add a parameter -v (verbose) and doing system.out only when this parameter is set. Additionally there would be a boolean property, because when I embed the reader I do not use the main() method. Do you agree? Eckard Jeremias Maerki [EMAIL PROTECTED] 07.03.2006 08:45 Bitte antworten an fop-users@xmlgraphics.apache.org An fop-users@xmlgraphics.apache.org Kopie Thema Re: Antwort: Re: Changing logging behavior in an embedded application. You're welcome to improve TTFReader in FOP Trunk if it doesn't do exactly what you want it to do. TTFReader was never designed to be used as anything else than a command-line tool which is called once for each font. If people have additional needs we're gladly accepting patches against FOP Trunk. On 07.03.2006 08:23:56 Eckard_Buchner wrote: FOP does have a few System.out.println calls in its source code but these are only in places where those are ok, i.e. in command-line handling code IMHO this is not the case with the TTFReader. It tells you about each file it reads and writes. If you convert a couple of files at once this is a little inconvenient. Maybe it should have a silent mode? BTW if you embed the TTF Reader i would prefer getting exceptions when something goes wrong rather than geting null return (and a stack trace in stdout) snip/ Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing logging behavior in an embedded application.
you are right the trunk version is fine. I am still using the 0.20 version but I will soon upgrade Eckard Jeremias Maerki [EMAIL PROTECTED] 07.03.2006 10:17 Bitte antworten an fop-users@xmlgraphics.apache.org An fop-users@xmlgraphics.apache.org Kopie Thema Re: Antwort: Re: Antwort: Re: Changing logging behavior in an embedded application. If the TTFReader is supposed to be used as an embedded component, it's best to separate the logic from the command-line interface. System.out calls would then not be permitted in the logic, only in the command-line interface. I don't like when things are mixed. I've just had a look at the code and as far as I can see, all log calls go to the logger, so it would actually be only a matter of setting up the logging right in your case. You may not even have to change anything. I did not remember that the whole thing was so well cleaned-up already. On 07.03.2006 10:06:31 Eckard_Buchner wrote: i could do something like this: Add a parameter -v (verbose) and doing system.out only when this parameter is set. Additionally there would be a boolean property, because when I embed the reader I do not use the main() method. Do you agree? Eckard Jeremias Maerki [EMAIL PROTECTED] 07.03.2006 08:45 Bitte antworten an fop-users@xmlgraphics.apache.org An fop-users@xmlgraphics.apache.org Kopie Thema Re: Antwort: Re: Changing logging behavior in an embedded application. You're welcome to improve TTFReader in FOP Trunk if it doesn't do exactly what you want it to do. TTFReader was never designed to be used as anything else than a command-line tool which is called once for each font. If people have additional needs we're gladly accepting patches against FOP Trunk. On 07.03.2006 08:23:56 Eckard_Buchner wrote: FOP does have a few System.out.println calls in its source code but these are only in places where those are ok, i.e. in command-line handling code IMHO this is not the case with the TTFReader. It tells you about each file it reads and writes. If you convert a couple of files at once this is a little inconvenient. Maybe it should have a silent mode? BTW if you embed the TTF Reader i would prefer getting exceptions when something goes wrong rather than geting null return (and a stack trace in stdout) snip/ Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: Re: Changing logging behavior in an embedded application.
FOP does have a few System.out.println calls in its source code but these are only in places where those are ok, i.e. in command-line handling code IMHO this is not the case with the TTFReader. It tells you about each file it reads and writes. If you convert a couple of files at once this is a little inconvenient. Maybe it should have a silent mode? BTW if you embed the TTF Reader i would prefer getting exceptions when something goes wrong rather than geting null return (and a stack trace in stdout) Eckard Jeremias Maerki [EMAIL PROTECTED] 07.03.2006 08:05 Bitte antworten an fop-users@xmlgraphics.apache.org An fop-users@xmlgraphics.apache.org Kopie Thema Re: Changing logging behavior in an embedded application. Hmm, FOP does not do anything special with warning messages as opposed to debug- or info-level messages. If you managed you reroute all logging to java.util.logger it's a matter of configuring that thing correctly. FOP does have a few System.out.println calls in its source code but these are only in places where those are ok, i.e. in command-line handling code. Your other post about the Verdana font showed that you're not calling FOP's command-line so everything does go through the logging abstraction. Did you specify a logging config file using -Djava.util.logging.config.file= and properly set up the handlers? On 06.03.2006 13:07:23 Tracey Zellmann wrote: Thanks. I had been to that page. I have got a basic solution. I can get everything logged to a java.util.Logger, behaving the way I want. However, I am still getting all the FOP WARNING messages coming to the console. I was able to get a workable solution to that using redirection from the main command that starts my Swing application, 2fopMessages.txt sends all the command warning messages to that file and overwrites each session. However, I would like to find a cleaner approach. Is there a simple way to turn off the logging to the console? - Original Message - From: Jeremias Maerki [EMAIL PROTECTED] To: fop-users@xmlgraphics.apache.org Sent: Monday, March 06, 2006 3:52 AM Subject: Re: Changing logging behavior in an embedded application. Apache FOP uses Apache Jakarta Commons Logging as a logging abstraction kit. [1] should give you the basics and has links to further information on configuring logging the way you want it to behave. I hope that helps. [1] http://xmlgraphics.apache.org/fop/0.91/embedding.html#basic-logging On 04.03.2006 20:44:55 Tracey Zellmann wrote: I have dug through what documentation I can find, but it hasn't helped me, so maybe the list can give me some guidance. I have my application running successfully. I am using fop 0.91beta-bin-jdk1.4 It publishes a PDF using FOP within another java application, not from the command line, so I believe you would call it embedded. I need to change the way logging messages are handled. Currently, I am getting a large number of warning messages printed to the console. With Jeremias Maerki's help, I can see they are caused my some namespace issues with some imported svg images I am using from MS Visio. Essentially, they can be ignored, and that is what I have been doing. However, next week, I have to turn this over to the first wave of normal users, so I don't want to overwhelm them with these messages. I would like all messages to go to a log file, not the console. I would prefer that warning level messages go to a file that is typically overwritten, so they don't accumulate. Anything higher than warning should go to another file which does append and accumulates the message history. I am pretty sure I could handle this using Java's java.util.logging API. However, I am not sure how to get hold of and change the current behavior of FOP logging. Can someone illuminate this for me? Thanks. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
register fonts with font-embedding off
Hi everybody, the embed-file attribute is optional according to the documentation, but the resulting pdf does not work with the acrobat reader: Cannot find or create the font '...' If the attribute is set then the pdf is ok. Here is what is happening - creating the font metrics files from the Windows Verdana font files - creating the font configuration file with or without embedding the ttfs. - using the same font name Verdana that the FOP TTFReader has extracted from the font (that is the fonts name according to the windows font property dialog) - loading the configuration before starting the driver I will be happy to provide the font metrics files, fop configuration file, the FO input and the PDFs with and without embedding. They are not attached here because I'm not sure if this is against the house rules thanks Eckard
Antwort: Re: register fonts with font-embedding off
It's been said on this list before that not embedding TrueType fonts doesn't work. TrueType fonts always need to be embedded if the XML font metric file has been generated without the -enc ansi option. With -enc ansi the TrueType font can be used but not embedded, but you are then restricted to the WinAnsi character set. Sorry for not checking the archives first. Is this a PDF or FOP limitation? Either embedding a font or being restricted to WinAnsi? I'm embedding fonts mainly to generate reports with non-standard character sets. Eckard
Problems with czech characters
Hello, our Czech customers tell us that not all czech characters are printed correctly with the built-in pdf fonts. For example R-caron is not part of the font table in the pdf specification. If we embed a true type font then it is fine, but we have not found a suitable font to ship with our application (license restrictions or heavy license fees) Has anybody experienced similar problems? How can I make use of the fonts that acrobat reader comes with (Minion ...). Are these fonts available on all platforms? These fonts contain most foreign characters Thanks Eckard
