Re: [VOTE:RESULT] Luca Furini for Committer
Luca, is your CLA on its way? On 27.09.2004 18:13:32 Luca Furini wrote: Luca, you are now a FOP committer. Wow, thanks for the warm welcome, I'll try hard to be up to my new role! Full name:Luca Furini Preferred userid: lfurini (unix account name) Forwarding email address: [EMAIL PROTECTED] I'm filling in the CLA; I will send it as soon as possible. Jeremias Maerki
Re: PS Interpreter
Thanks for the update, Victor. I absolutely want to have a look at this. So this is really the foundation to make Type 1 fonts available on the fly without generating font metric XML files by hand. Very cool. It'll be fun to see if I can get some basic ops working to paint some simple shapes to a Graphics2D interface. On 07.10.2004 03:54:33 Victor Mote wrote: FWIW, the FOray PostScript interpreter is now able to successfully parse any Type 1 font that I have thrown at it, store the data structures, and retrieve them. This includes the ability to parse the encrypted portion of the font, whether in binary or ASCII hexadecimal. The FOray font package is therefore now able to correctly gather the FontBBox and StemV values for a PDF. (The ItalicAngle has also been elusive -- it is actually in the PFM file under the name etmSlant. The FOray package now parses and uses it as well.) I think this means that all of the elusive, estimated pieces are now correctly computed using 1) either a PFA or PFB file and 2) a PFM file. This will also help in future subsetting work, and font embedding enhancements (like converting ASCII hex fonts to binary to make the file smaller). Since the parsing takes some extra time and memory, I may need to provide ways to cripple or partially cripple this process for users who don't want to pay that much for the benefit. An AFM parser is still needed, primarily so that users can conveniently override values if they need to. But I think the backwards-compatible ability to not require an AFM file is nice. The PostScript parser itself is pretty rudimentary. After pulling the errors and obvious non-operator items out of the list, there appear to be 352 operators for Level 2 compliance. I have only implemented 42 of them so far. However, a lot of the brain-bending part of the design work is done, and I think it should be a good starting place for other PostScript-related projects, like EPS conversion. Here is the ViewCVS link to the PSInterpreter: http://cvs.sourceforge.net/viewcvs.py/foray/foray/foray-ps/src/java/org/fora y/ps/PSInterpreter.java?view=markup The other files are in the same directory. I'll probably leave it alone until I need more from it, but I wanted to update Jeremias and anyone else who is interested. Victor Mote Jeremias Maerki
Re: PS Interpreter
Jeremias Maerki wrote: Thanks for the update, Victor. I absolutely want to have a look at this. So this is really the foundation to make Type 1 fonts available on the fly without generating font metric XML files by hand. Very cool. It'll be fun to see if I can get some basic ops working to paint some simple shapes to a Graphics2D interface. I'll be watching with interest. Peter On 07.10.2004 03:54:33 Victor Mote wrote: FWIW, the FOray PostScript interpreter is now able to successfully parse any Type 1 font that I have thrown at it, store the data structures, and retrieve them. This includes the ability to parse the encrypted portion of the font, whether in binary or ASCII hexadecimal. -- Peter B. West http://cv.pbw.id.au/
DO NOT REPLY [Bug 31580] New: - fo:external-graphic does not work when src is an image URL which is in a jar-file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31580.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31580
fo:external-graphic does not work when src is an image URL which is in a jar-file
Summary: fo:external-graphic does not work when src is an image
URL which is in a jar-file
Product: Fop
Version: 0.20.5
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: images
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Hi!
I found a problem when using url instead of file for fo:external-graphic's
src paramater (FOP is 0.20.5 distribution). for example,
fo:external-graphic height=15pt width=180pt
xsl:attribute name=srcurl('/my/image/image.gif')/xsl:attribute
/fo:external-graphic
it will work with the following changes in class
org.apache.fop.image.FopImageFactory.java
...
// Try to find the image as a class-resource first (for instance in a jar-
file)...
try {
imgIS = FopImageFactory.class.getResourceAsStream(href);
absoluteURL = FopImageFactory.class.getResource(href);
} catch (Exception e) {
}
if (imgIS == null) {
try {
// try url as complete first, this can cause
// a problem with relative uri's if there is an
// image relative to where fop is run and relative
// to the base dir of the document
try {
absoluteURL = new URL(href);
} catch (MalformedURLException mue) {
// if the href contains onl a path then file is assumed
absoluteURL = new URL(file: + href);
}
imgIS = absoluteURL.openStream();
} catch (MalformedURLException e_context) {
throw new FopImageException(Error with image URL:
+ e_context.getMessage());
} catch (Exception e) {
// maybe relative
URL baseURL = Configuration.getBaseURL();
if (baseURL == null) {
throw new FopImageException(Error with image URL:
+ e.getMessage()
+ and no base URL is specified);
}
try {
/*
This piece of code is based on the following statement in
RFC2396 section 5.2:
3) If the scheme component is defined, indicating that
the reference
starts with a scheme name, then the reference is
interpreted as an
absolute URI and we are done. Otherwise, the
reference URI's
scheme is inherited from the base URI's scheme
component.
Due to a loophole in prior specifications [RFC1630],
some parsers
allow the scheme name to be present in a relative
URI if it is the
same as the base URI scheme. Unfortunately, this
can conflict
with the correct parsing of non-hierarchical URI.
For backwards
compatibility, an implementation may work around
such references
by removing the scheme if it matches that of the
base URI and the
scheme is known to always use the hier_part syntax.
The URL class does not implement this work around, so
we do.
*/
String scheme = baseURL.getProtocol() + :;
System.out.println(scheme + scheme);
if (href.startsWith(scheme)) {
href = href.substring(scheme.length());
}
System.out.println(href after + href);
absoluteURL = new URL(baseURL, href);
} catch (MalformedURLException e_context) {
throw new FopImageException(Invalid Image URL - error on
relative URL :
+ e_context.getMessage());
}
}
}
// If not, check image type
ImageReader imgReader = null;
...
RE: PS Interpreter
Jeremias Maerki wrote: So this is really the foundation to make Type 1 fonts available on the fly without generating font metric XML files by hand. Very cool. Actually, FOray eliminated the intermediate font metric XML files several months ago, and parses the TTF, PFM, PFA, and PFB files on-the-fly. I'll try to add an AFM parser in the next few days, and then I think we'll have the best of all worlds -- you can hand-tune an AFM file if you want to, but otherwise, just use the files that ship with the font. We may have some performance/memory issues that result from this, but I think the code is set up to accommodate some configuration items after I start getting some feedback about what people want. BTW, I want to compliment the people that wrote the original font code. There was really a large amount of good and useful code in there. I spent several months refactoring it to make it cleaner and easier to use, but I came out *way* ahead of starting over again. My current theory about open-source development is that, because so many people work on it, it evolves into something that is a bit convoluted. Every once in a while, you need a refactoring cycle to clean it up (really to impose or reimpose a design after-the-fact). My current theory also includes the idea that nobody really wants to do that work, because it isn't very much fun, and because it is hard to see an immediate benefit. Anyway, my compliments to Tore and Jeremias and the many others who wrote the base code. Victor Mote
