DO NOT REPLY [Bug 17521] - Fonts in PDF
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=17521. 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=17521 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] ||forum.de OS/Version||All -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 31936] New: - [PATCH] Fonts are rendered differently between pdf and awt
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=31936. 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=31936 [PATCH] Fonts are rendered differently between pdf and awt Summary: [PATCH] Fonts are rendered differently between pdf and awt Product: Fop Version: 0.20.5 Platform: PC OS/Version: Windows XP Status: NEW Severity: Minor Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The userconfig.xml contains a fonts tag enabling custom fonts to be used in rendering. The awt and pdf output render these fonts differently. A way to render such fo documents more consistantly across different outputs is to enable configuration roles for the fonts xml tag.
DO NOT REPLY [Bug 31936] - [PATCH] Fonts are rendered differently between pdf and awt
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=31936. 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=31936 [PATCH] Fonts are rendered differently between pdf and awt --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 14:03 --- Created an attachment (id=13246) Describes the source changes to enable roles to be defined in the userconfig.xml
DO NOT REPLY [Bug 31936] - [PATCH] Fonts are rendered differently between pdf and awt
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=31936. 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=31936 [PATCH] Fonts are rendered differently between pdf and awt --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 14:21 --- Created an attachment (id=13248) A simple fo document to replicate the error with.
DO NOT REPLY [Bug 31936] - [PATCH] Fonts are rendered differently between pdf and awt
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=31936. 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=31936 [PATCH] Fonts are rendered differently between pdf and awt --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 14:23 --- Created an attachment (id=13249) Fop configuration xml file
DO NOT REPLY [Bug 31936] - [PATCH] Fonts are rendered differently between pdf and awt
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=31936. 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=31936 [PATCH] Fonts are rendered differently between pdf and awt --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 14:28 --- Created an attachment (id=13250) An executable batch file to show the difference between pdf and awt outputs
DO NOT REPLY [Bug 31936] - [PATCH] Fonts are rendered differently between pdf and awt
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=31936. 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=31936 [PATCH] Fonts are rendered differently between pdf and awt --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 14:30 --- Created an attachment (id=13251) Example fop config xml that works with the patched files.
DO NOT REPLY [Bug 31936] - [PATCH] Fonts are rendered differently between pdf and awt
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=31936. 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=31936 [PATCH] Fonts are rendered differently between pdf and awt --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 15:55 --- Hi Peter: What you propose here is interesting, but I am a bit confused. You have split the font configuration into two parts, one for awt and one for pdf, and I see a few differences between them, but I don't understand what these differences are accomplishing. Would you please elaborate a bit on *why* this change solved your problem? My current theory is that any improvement that you have in making awt comparable to pdf is probably due to unintentionally getting the awt renderer to use the free-standing fonts instead of the system fonts (see below) or maybe vice versa. Also, the issue is somewhat bigger than awt vs. pdf, although that can be solved by adding some more roles. The real issue is system fonts (those registered with the o/s), which awt uses, vs. what I call free-standing fonts (those using an independent registration system), which pdf and PostScript use. System fonts don't use or need most of the stuff in the font configuration. The fonts used by the two systems can be different, and even if the fonts are identical, the metrics are obtained differently between the two systems. I have spent much of the past six months refactoring and improving the FOP font system, and I have partly addressed the issue that you mention, by adding a system-font element in the font configuration file. It doesn't do much ATM except recognize that there is a difference. See the notes here: (http://www.foray.org/release.html). If you will elaborate a bit on what you would like to see happen, I am interested. Victor Mote
DO NOT REPLY [Bug 28705] - PDF Text search doesnt work for embedded fonts.
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=28705. 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=28705 PDF Text search doesnt work for embedded fonts. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-09-23 10:18 --- Cause: Missing ToUnicode maps. *** This bug has been marked as a duplicate of 5335 ***
DO NOT REPLY [Bug 5335] - Text with embedded CID fonts not retrievable from pdf
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=5335. 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=5335 Text with embedded CID fonts not retrievable from pdf [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-09-23 10:18 --- *** Bug 28705 has been marked as a duplicate of this bug. ***
DO NOT REPLY [Bug 5335] - Text with embedded CID fonts not retrievable from pdf
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=5335. 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=5335 Text with embedded CID fonts not retrievable from pdf --- Additional Comments From [EMAIL PROTECTED] 2004-09-23 13:52 --- This issue has been fixed in FOray CVS, and should be available in FOray 0.2: http://www.foray.org/release.html.
Re: adding fonts to fop applet
On Fri, Jul 09, 2004 at 03:05:11PM -0700, Glen Mazza wrote: Thanks, Simon. Its good that we have people of your skill on our team. Thanks for the compliment. Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: adding fonts to fop applet
Errr--I apologize--I forgot that we had already agreed to use Avalon for configuration [1]. Sorry/Never mind... Glen [1] http://marc.theaimsgroup.com/?l=fop-devm=108337684719819w=2 --- Glen Mazza [EMAIL PROTECTED] wrote: --- Simon Pepping [EMAIL PROTECTED] wrote: - From an app: add a configuration object to the FOUseragent object, Why do you need to drag in the Avalon library for this? For the classes in question, Avalon is just providing a very thin wrapper--can't we do this directly against the JDK? Glen
Re: adding fonts to fop applet
--- Simon Pepping [EMAIL PROTECTED] wrote: - From an app: add a configuration object to the FOUseragent object, Why do you need to drag in the Avalon library for this? For the classes in question, Avalon is just providing a very thin wrapper--can't we do this directly against the JDK? Glen
Re: adding fonts to fop applet
--- Simon Pepping [EMAIL PROTECTED] wrote: Well, was, I hope. I have just committed code which enables using a user configuration file and adding fonts from it. Thanks, Simon. Its good that we have people of your skill on our team. Glen
DO NOT REPLY [Bug 21303] - Embeded Fonts and signets disturbed by encryption
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=21303. 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=21303 Embeded Fonts and signets disturbed by encryption [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Windows NT/2K |All Platform|PC |All --- Additional Comments From [EMAIL PROTECTED] 2004-06-22 18:28 --- Please realize that the bug won't be fixed for FOP 0.20.5 as this line of development is frozen in favor of the main development direction (CVS HEAD) where the bug is already fixed. You've seen the work-around I posted in an earlier entry for this bug, haven't you?
DO NOT REPLY [Bug 21303] - Embeded Fonts and signets disturbed by encryption
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=21303. 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=21303 Embeded Fonts and signets disturbed by encryption --- Additional Comments From [EMAIL PROTECTED] 2004-06-21 08:20 --- this not only appears unter windows (also my windows fop-version (0.20.5) ignores the -nocopy, -noedit, -o flags). this also is true for the linux version. it is very anoying. markus
DO NOT REPLY [Bug 29632] New: - Rendered reads fonts from disk everytime it renders PDF.
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=29632.
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=29632
Rendered reads fonts from disk everytime it renders PDF.
Summary: Rendered reads fonts from disk everytime it renders PDF.
Product: Fop
Version: 0.20.4
Platform: HP
OS/Version: HP-UX
Status: NEW
Severity: Major
Priority: Other
Component: pdf renderer
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Even if you reuse an instance of a Driver object, renderer reads all font
definitions (.xml) from disk everytime it processes a document. Font instances
are not reused, a lot of memory is allocated and freed immediately, IO
operations are huge.
You can try the following code to see how it behaves.
import org.apache.fop.configuration.ConfigurationReader;
import org.apache.fop.apps.InputHandler;
import org.apache.fop.apps.Driver;
import org.xml.sax.InputSource;
import javax.xml.transform.stream.StreamSource;
import javax.xml.transform.stream.StreamResult;
import javax.xml.transform.*;
import java.io.*;
import java.util.Date;
public class FOP {
public static void main(String[] args) {
try {
StreamSource ss = new StreamSource(new StringReader(
Put XML here ));
StreamSource ss2 = new StreamSource(new StringReader( Put XSL here
));
TransformerFactory tf = TransformerFactory.newInstance
();
Templates ts = tf.newTemplates(ss2);
Transformer t = ts.newTransformer();
ByteArrayOutputStream resultstream = new
ByteArrayOutputStream();
Result res = new StreamResult(resultstream);
t.transform(ss, res);
ConfigurationReader reader = new ConfigurationReader
(InputHandler.fileInputSource(new File(/xslconfig/conf/userconfig.xml)));
reader.start();
ByteArrayOutputStream fos = new ByteArrayOutputStream();
ByteArrayInputStream fis = new ByteArrayInputStream
(resultstream.toByteArray());
ByteArrayInputStream fis2 = new ByteArrayInputStream
(resultstream.toByteArray());
InputSource is = new InputSource(fis);
InputSource is2 = new InputSource(fis2);
System.out.println(new Date() + Sleeping for 20
seconds before first rendering, check IO read bytes now...);
Thread.sleep(2);
Driver driver = new Driver(is, fos);
driver.run();
System.out.println(new Date() + Sleeping for 20
seconds after first rendering, check IO read bytes now...);
Thread.sleep(2);
driver.setInputSource(is2);
driver.setOutputStream(fos);
driver.run();
System.out.println(new Date() + Sleeping for 20
seconds after seconds rendering, check IO read bytes now...);
Thread.sleep(2);
} catch (Exception e) {
e.printStackTrace();
}
}
}
DO NOT REPLY [Bug 28705] - PDF Text search doesnt work for embedded fonts.
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=28705. 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=28705 PDF Text search doesnt work for embedded fonts. --- Additional Comments From [EMAIL PROTECTED] 2004-06-04 08:09 --- The bfrange-section in the metrics file was filled correctly. Can I use these values as a cmap section in the pdf?
RE: Fonts
Victor Mote [EMAIL PROTECTED] wrote on 25.05.2004 01:46:50: However, since these same fonts could also be used by the PostScript renderer, or the Print or AWT renderers (assuming that the pfb is available as well), I don't see a need to duplicate their definitions, or metrics, or anything for each one of these environments, which is what it sounds like you might be suggesting. Yes, but the base-14 fonts for example are not defined for AWT renderers, since *only* their metrics is publicly available. Still, in the case of the base 14-fonts you can really argue that you want to extend the PDF model of (these fonts are always there). Just note that on many systems you are out of luck with - for example - the Zapf Dingbats fonts. It should be sufficient for the Renderer (or RenderContext) to tell what it is *capable* of doing, without having to provide the actual detail. In the case of the Base-14 font metrics, we can and should and do embed them within FOP itself. In the case of an AFP renderer your model would suggest to the formatter that the 4 faces of Helvetica, Times Roman and Courier are available which they are not. At least, you would have to supply additional information so that the formatter could decide which of the standard fonts is available to which renderer. Why is this better than simply supplying the same font metrics at a global level, and letting the Renderer or RenderContext tell what it is/is not capable of processing? What would one get in return for giving up that simplicity? You would gain simplicity in another respect - you would exactly know which font (and not only which *type* of font is available to which renderer or device (in the latter case, think about output to different printers from the same installation, which could have a differing set of device fonts). Arnd -- Arnd Beißner Cappelino Informationstechnologie GmbH
RE: Fonts
Arnd Beißner wrote:
Arnd
Yes, but the base-14 fonts for example are not defined for AWT
renderers, since
*only* their metrics is publicly available. Still, in the case of
the
base 14-fonts you can really argue that you want to extend the PDF
model of
(these fonts are always there). Just note that on many systems you
are out
of luck with - for example - the Zapf Dingbats fonts.
/Arnd
Victor
I dont work with the AWT renderer, but it *should* be able to use the
base-14 fonts, assuming that the user has installed the font (not just the
metrics) on their system. It is true that only the metrics for base-14 fonts
are *freely* available, but the outlines *can* be licensed. In fact, I am
pretty sure they are all included in Adobe's Type1 version of its Type
Basics:
http://www.adobe.com/type/browser/P/P_934.jhtml
Your point is well taken that not all fonts are usable everywhere, but I do
like the idea of letting the *user* decide what those limitations are. For
example, in the example you gave of the device using bitmapped fonts, a user
might want to build PDF files at client machines that get queued up for a
machine that drives the printer itself. I think it is a good thing for
them to be able to do this. It is true that the view from within Acrobat
Reader is going to look different from the printed output, but I want to be
careful about artificially limiting the possibilities.
/Victor
Arnd
Victor
It should be sufficient for the Renderer (or
RenderContext) to tell what it is *capable* of doing, without
having to
provide the actual detail. In the case of the Base-14 font
metrics, we can
and should and do embed them within FOP itself.
/Victor
In the case of an AFP renderer your model would suggest to the
formatter
that the 4 faces of Helvetica, Times Roman and Courier are available
which
they are not. At least, you would have to supply additional
information
so that the formatter could decide which of the standard fonts is
available
to which renderer.
Victor
Why is this better than simply supplying the same font metrics at
a global
level, and letting the Renderer or RenderContext tell what it
is/is not
capable of processing? What would one get in return for giving up
that
simplicity?
/Victor
You would gain simplicity in another respect - you would exactly
know
which font (and not only which *type* of font is available to which
renderer or device (in the latter case, think about output to
different
printers from the same installation, which could have a differing
set of
device fonts).
/Arnd
OK, but doesn't this mean that now the user has to write a subclass of some
Renderer in order to manage his fonts? It seems like a lot of this can be
handled in the font configuration side of things, which allows it to be more
easily accessible by the user.
In the example you give, the worst case scenario is that the AFP device gets
a document it can't handle or that looks awful when it is output. It is
totally within the user's ability to prevent and correct this. So really
what we are talking about is how to prevent the user from doing something
stupid. Even this can be prevented by forcing the user to use a font
configuration that only contains the fonts available.
Nevertheless, I have no objection in principle to giving the Renderer this
level of control if it needs or wants it. Here is what I propose -- the
forayFont API design has an interface for a FontConsumer, which the client
application must supply when it is accessing font services. We'll just add a
method, something like:
boolean canProcessFontFamily(String fontFamily)
/* or perhaps the following, which would allow
FontConsumer to query the Font in more detail
about itself before deciding */
boolean canProcessFont(Font font)
The Renderer will need to simply respond false when a font is presented
that it doesn't know how to handle. The font system can then throw an
exception back to the client application saying that the Renderer has
rejected the font.
This would *allow*, but not really *require* a Renderer to manage fonts at
the level of detail that you envision. So most Renderers could simply:
boolean canProcessFont(Font font) {
return true;
}
I have added some comments regarding this to the FontConsumer section:
http://foray.sourceforge.net/module/font/index.html#api-design
This seems to address both of the competing concerns:
* your major concern that the Renderer have more control
* my major concern that fonts and font logic be removed from the
Renderers
It also seems to have the advantage of allowing the font subsystem to pull
information out of the Renderer as needed rather than having the Renderer
push everything it knows to the font system
Re: Fonts
On May 24, 2004, at 8:57 AM, Victor Mote wrote: Clay Leeds wrote: On the subject of running headless, my experience has been to pass it off to POSTSCRIPT--which, again in my experience--runs fine headless. Off the top of my head, I can't think of a reason that the PostScript renderer would work and the PDF renderer not work. I run all of my stuff in a headless environment to PDF, with no problems. If you can provide some details here, I am very interested to identify any RenderContext differences. Victor Mote Actually, we wanted to use '-print' but it was complicated by the 'headless' problem on AIX, so we went to '-ps' (PostScript), and did a 'cat %1 lpr' (approximation). Don't get me wrong (apologies if I gave that impression!)--PDF works well, unless we need SVG/Batik. Web Maestro Clay
Re: Fonts
Peter B. West wrote: Which is more sensible - writing a renderer's font handling to a common renderer font interface as an integral part of the renderer implementation, or discovering the fonts quirks of this particular renderer and adding them separately to a central font handler/registry? I wrote: The latter is outside my scope of knowledge (but sounds messy ;)--as for the former, what font-specific methods (and their signatures) do you see us needing to add to our render.Render interface (which declares the minimal methods needed by layout to interact with a renderer)? getFontMetrics()? isFontSupported()? (Currently, there is just a setupFontInfo() in this interface, which, as you say, seems nonideal--layout feeding the renderers the FontInfo.) At the moment, I don't see any font-specific methods required. (Still learning...) But wouldn't we need to add some form of isFontSupported(fontName, ...) to the Renderer interface? AFAICT, the XSL font-family property allows me to specify any font I want, so long as it is supported by the RenderType I chose. So if I invent a new RenderType, say Glen Document Format (GDF), and invent a new font for it, Glen Font, isFontSupported(Glen Font) would return true for the -gdf output type and false for the -pdf output type. Then, layout would use that boolean value to determine whether it needs to fall back to a backup/default font. Also, (this point I'm less certain on) a getFontMetrics(fontName) of some sort would be needed so layout can determine how much space Mary had a Little Lamb would consume using my new font on the defined output type, correct? getFontMetrics() could be centralized in one place instead of being renderer-specific, but if so we may need to handle the issue of multiple renderers possibly having the same name for a font type but different metrics/meanings for them. (E.g., courier new having different sizes in awt than it would in pdf, or a render type short-circuiting a popular font that it doesn't support to a similar supported one with slightly different metrics.) Thanks, Glen
Re: Fonts
On May 23, 2004, at 5:32 PM, Victor Mote wrote: Glen Mazza wrote: (Far from being an expert on fonts, but commenting anyway... ;) Ahem... possibly even farther from being an expert on fonts... and commenting anyway ;-) (mildly OT: BTW, nice to have you 'back' [EMAIL PROTECTED] hope to/glad we'll be hearing more from you in the future...) Peter B. West wrote: I have been exploring the way fonts are handled by Java as part of setting up a Java layout engine and renderer. I have committed a new class - org.apache.fop.render.awt.fonts - as a first cut at a fonts database for this application. I will attach the class description to this email. The last time I checked, there was no way to get to the physical font file through the awt interface. It is possible that java.awt.font.OpenType can provide some or all of what is needed for TTF and OT fonts, but I don't know of a way to handle Type1 embedding at all. This means that you cannot ever embed the said font, unless you set up a parallel system (similar to the way FOP handles things now) to find the physical file. Another issue is headless environments. I once went down the path of trying to figure out how to register fonts in a headless environment, and frankly don't remember what I learned. It is probably possible. On the subject of running headless, my experience has been to pass it off to POSTSCRIPT--which, again in my experience--runs fine headless. Perhaps something can be 'learned' from that interaction? Maybe instead of basing the implementation on AWT, it might make sense to base it instead off of POSTSCRIPT. Alternatively, perhaps Type1 might 'require' postscript? Dunno... just a thought... Web Maestro Clay
Re: Fonts
Glen Mazza wrote: Peter B. West wrote: I wrote: The latter is outside my scope of knowledge (but sounds messy ;)--as for the former, what font-specific methods (and their signatures) do you see us needing to add to our render.Render interface (which declares the minimal methods needed by layout to interact with a renderer)? getFontMetrics()? isFontSupported()? (Currently, there is just a setupFontInfo() in this interface, which, as you say, seems nonideal--layout feeding the renderers the FontInfo.) At the moment, I don't see any font-specific methods required. (Still learning...) But wouldn't we need to add some form of isFontSupported(fontName, ...) to the Renderer interface? AFAICT, the XSL font-family property allows me to specify any font I want, so long as it is supported by the RenderType I chose. So if I invent a new RenderType, say Glen Document Format (GDF), and invent a new font for it, Glen Font, isFontSupported(Glen Font) would return true for the -gdf output type and false for the -pdf output type. Then, layout would use that boolean value to determine whether it needs to fall back to a backup/default font. That would be covered in the combination of getFont(...) and selectionStrategy. If the selection strategy excludes intelligent font substitution, and the given font family is not available, return null. If intelligent substitution is allowed, then let the renderer select another font family. It's worth reading the relevant parts of the Fonts section in the CSS2 spec for some insight into the recommended font selection strategy. XSL-FO adds another twist through font-selection-strategy. The font-family property returns a list, the idea being that a series of family-names or generic-names can be tried in sequence to resolve a font. I'll have to read the CSS2 description again to determine exactly how . Also, (this point I'm less certain on) a getFontMetrics(fontName) of some sort would be needed so layout can determine how much space Mary had a Little Lamb would consume using my new font on the defined output type, correct? getFontMetrics() could be centralized in one place instead of being renderer-specific, but if so we may need to handle the issue of multiple renderers possibly having the same name for a font type but different metrics/meanings for them. (E.g., courier new having different sizes in awt than it would in pdf, or a render type short-circuiting a popular font that it doesn't support to a similar supported one with slightly different metrics.) The font metrics would be implicit in the Font (or FopFont) object returned from the renderer. Having the renderers (explicitly or implicitly) returning the Font object ensures that the layout's notion of metrics is the same as that of the renderer. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
RE: Fonts
Peter B. West wrote: One important point here is that, even if awt font handling were the correct *implementation* of font handling to use, there would still be, IMO anyway, utility in hiding even that fact from the rest of FOP, certainly no harm. What I'm exploring is the possibility of going in the opposite direction. That is, using the Interfaces and Classes of java text layout as a model for FOP layout, even if the implementation is FOP specific. That way, when the Java model *is* adequate for FOP's use, it is a trivial matter. The 2D model of text layout seems very powerful. This is only opposite in the sense of how the abstraction works. Your approach is pretty sound, and, assuming that you can solve the embedding problem, has some merit. However, there is no reason that the isolated Font logic can't use the awt objects that you are interested in to do the work behind the interface that FOray is building (or something similar). By isolating all of this code, you can have your cake and eat it too. You can use awt if, when, and how much it really makes sense, and you can do all kinds of other stuff as well for places where awt is inadequate. For example, awt gives access to the OpenType tables, but really doesn't do anything with them. FOray wants to use that information, and I assume that FOP will eventually want to also. So, why limit yourself to awt? As I said before, even if awt were perfect, there is still value in hiding it, especially during a refactoring stage. Again, the underlying font is the same whether you are rendering to PDF, Postscript, or anything else. Only the embedding would change. Please let me know if I have missed something. Given a logical layout, the final result is determined by the renderer's notion of glyphs, their metrics and their relationships. Is this not so? Yes, and the renderer gets that information from the Font, which is still the same Font, and has no idea who is using it or why or how. I don't deny that the concept I have described as RenderContext (you may have been off-line when we discussed this about a year ago) may affect layout. Those differences must be considered during layout (but the logic of handling them should not be done by the layout classes). RenderContext describes the capabilities that are available, presumably what fonts are available in this context, but could also include other things (can't kern, can't do letter-spacing, can't stretch text, etc). AFAICT, PDF and PostScript use the same RenderContext, but if there are differences, then they can each have their own. Once these capabilities are defined, they must be considered as the FOTree is built, and as layout is performed. So, while the Font is always a constant, it needs to be filtered through the lens of the RenderContext before it can be used properly. That is probably why the Font stuff ended up in the Render classes. And that is (part of) why I think, as FOP grows up here, it is important to distinguish between the Renderer and the RenderContext. If you'll give me a few weeks, I hope to be able to show you what I seem unable to sell with words. Victor Mote
RE: Fonts
Clay Leeds wrote: On the subject of running headless, my experience has been to pass it off to POSTSCRIPT--which, again in my experience--runs fine headless. Off the top of my head, I can't think of a reason that the PostScript renderer would work and the PDF renderer not work. I run all of my stuff in a headless environment to PDF, with no problems. If you can provide some details here, I am very interested to identify any RenderContext differences. Victor Mote
RE: Fonts
Arnd Beißner wrote: To all of that I entirely agree, but might want to add one thing: a renderer should have a way to supply a font to the formatter's font repository. This is needed when, for example, a print renderer can query and use builtin printer fonts. The way to query and get these (even if it's only a metrics-only font) should be in the renderer, though. Sometimes, this is an essential feature, for example for special OCR/OMR fonts stored in printers for which you may not have a screen font. One of the changes that will probably need to be made to FOP's font handling is to parse AFM files instead of PFMs. I have assumed that for hardware fonts, either the device manufacturer provides font metrics files or enough information so that they can be built. Adobe, for example, provides metrics for the base-35 PostScript device fonts here: ftp://ftp.adobe.com/pub/adobe/type/win/all/afmfiles/base35/ So my *plan* has been that these fonts get treated pretty much like any other font. The only thing about the hardware font is that it can't be embedded -- it is already embedded all of the places that it can be. Are you suggesting that FOP / FOray needs to actually query the hardware device and extract metrics information directly from it? Or is the plan I have outlined above sufficient? Victor Mote
Re: Fonts
On May 24, 2004, at 5:16 AM, Jeremias Maerki wrote: One big problem: As soon as you use SVG, you're running Batik code which makes heavy use of AWT. I think with three different approaches to solve the headless problem this shouldn't be a big issue, even on AIX, right? We punted on the Batik side of things... We don't use it at all (at least as far as I can tell). As far as AWT goes (which we are having to use to implement TIF output--I may have something to offer in the not-too-distant future in that regard), we've been able to implement a pass-thru of sorts, essentially tricking AIX 'video' to /dev/null. Hopefully, as you suggest, one of the three will work. Problem is, when the method you require has problems running headless (e.g., using AWT to output to TIF). Web Maestro Clay
RE: Fonts
Victor Mote [EMAIL PROTECTED] wrote on 24.05.2004 18:12:36: One of the changes that will probably need to be made to FOP's font handling is to parse AFM files instead of PFMs. I have assumed that for hardware fonts, either the device manufacturer provides font metrics files or enough information so that they can be built. Adobe, for example, provides metrics for the base-35 PostScript device fonts here: ftp://ftp.adobe.com/pub/adobe/type/win/all/afmfiles/base35/ This is what did in my formatter. I have implemented an AFM reader (though I ignore the kerning infos so far) and use this to read the Adobe base fonts - for example. So my *plan* has been that these fonts get treated pretty much like any other font. The only thing about the hardware font is that it can't be embedded -- it is already embedded all of the places that it can be. Depends. Every PDF compliant reader/printer has to support Adobe's standard Helvetica, Times Roman, Courier, Symbol and Zapf Dingbats fonts (metrics-compatible alternatives at least). So it makes sense for a PDF renderer to supply these fonts metrics to a formatter to say hey, I can render these. Are you suggesting that FOP / FOray needs to actually query the hardware device and extract metrics information directly from it? Or is the plan I have outlined above sufficient? Well, it really depends how far you want to go. Device fonts have certainly seen days of higher importance... But still, from time to time you stumble upon people who need (or want) to use fonts that they have no exact software equivalent for. Whether this means accessing the device directly or indirectly using a printer driver or by means of supplying metric files is a side issue, I think. Let's just say a renderer should be able to supply fonts (metric-only or complete) to the formatter. To give you an extreme example: In the high-volume output market, the format of choice is still AFP by IBM. This is (but today's standards) a rather obscure format that has ancient origins in the GKS system and is very similar to the metafile format in OS/2. Concerning fonts, however, you mostly use bitmap fonts in the AFP world. Imagine a renderer that has to support an output format that only allows (and supplies) bitmap fonts. Sure, it's debatable whether one want to support this kind of thing - at least by design. But, in any case, I think it highlights the extremes that can happen in the font handling world. Arnd -- Arnd Beißner Cappelino Informationstechnologie GmbH
RE: Fonts
Arnd Beißner wrote: So my *plan* has been that these fonts get treated pretty much like any other font. The only thing about the hardware font is that it can't be embedded -- it is already embedded all of the places that it can be. Depends. Every PDF compliant reader/printer has to support Adobe's standard Helvetica, Times Roman, Courier, Symbol and Zapf Dingbats fonts (metrics-compatible alternatives at least). So it makes sense for a PDF renderer to supply these fonts metrics to a formatter to say hey, I can render these. However, since these same fonts could also be used by the PostScript renderer, or the Print or AWT renderers (assuming that the pfb is available as well), I don't see a need to duplicate their definitions, or metrics, or anything for each one of these environments, which is what it sounds like you might be suggesting. It should be sufficient for the Renderer (or RenderContext) to tell what it is *capable* of doing, without having to provide the actual detail. In the case of the Base-14 font metrics, we can and should and do embed them within FOP itself. If you don't mind the metrics themselves living somewhere else, and the PDF Renderer simply saying I can render Base-14 fonts, then we are in agreement. Are you suggesting that FOP / FOray needs to actually query the hardware device and extract metrics information directly from it? Or is the plan I have outlined above sufficient? Well, it really depends how far you want to go. Device fonts have certainly seen days of higher importance... But still, from time to time you stumble upon people who need (or want) to use fonts that they have no exact software equivalent for. Whether this means accessing the device directly or indirectly using a printer driver or by means of supplying metric files is a side issue, I think. Let's just say a renderer should be able to supply fonts (metric-only or complete) to the formatter. Why is this better than simply supplying the same font metrics at a global level, and letting the Renderer or RenderContext tell what it is/is not capable of processing? What would one get in return for giving up that simplicity? To give you an extreme example: In the high-volume output market, the format of choice is still AFP by IBM. This is (but today's standards) a rather obscure format that has ancient origins in the GKS system and is very similar to the metafile format in OS/2. Concerning fonts, however, you mostly use bitmap fonts in the AFP world. Imagine a renderer that has to support an output format that only allows (and supplies) bitmap fonts. Sure, it's debatable whether one want to support this kind of thing - at least by design. But, in any case, I think it highlights the extremes that can happen in the font handling world. After you have a generic font definition scheme, like an AFM parser or FOP's metrics files, I think you can support any font, bitmap or otherwise. If the hardware vendors can't provide the metrics, then someone would have to sit down and either query the device or infer the metrics from output, or some other method to get it into the standard form expected. It might be worthwhile to add something in the font configuration that would identify the point size, so that at least a warning could be generated if someone tried to use, say, an 11-pt file at 9 points. Victor Mote
Re: Fonts
Victor Mote wrote: Peter B. West wrote: ... What I'm exploring is the possibility of going in the opposite direction. That is, using the Interfaces and Classes of java text layout as a model for FOP layout, even if the implementation is FOP specific. That way, when the Java model *is* adequate for FOP's use, it is a trivial matter. The 2D model of text layout seems very powerful. This is only opposite in the sense of how the abstraction works. Your approach is pretty sound, and, assuming that you can solve the embedding problem, has some merit. However, there is no reason that the isolated Font logic can't use the awt objects that you are interested in to do the work behind the interface that FOray is building (or something similar). By isolating all of this code, you can have your cake and eat it too. You can use awt if, when, and how much it really makes sense, and you can do all kinds of other stuff as well for places where awt is inadequate. For example, awt gives access to the OpenType tables, but really doesn't do anything with them. FOray wants to use that information, and I assume that FOP will eventually want to also. So, why limit yourself to awt? As I said before, even if awt were perfect, there is still value in hiding it, especially during a refactoring stage. I am interested in the 2D approach for a couple of reasons. Firstly, because I want a testbed for alt-design layout sooner rather than later. Secondly, I was looking for a approach to fonts and layout that was not PDF-centric and that might be familiar to new folks coming in, so the idea of modelling it on 2D appealed. Clearly, there is nothing of overwhelming relevance to HEAD in either approach. ... Yes, and the renderer gets that information from the Font, which is still the same Font, and has no idea who is using it or why or how. I don't deny that the concept I have described as RenderContext (you may have been off-line when we discussed this about a year ago) may affect layout. Those differences must be considered during layout (but the logic of handling them should not be done by the layout classes). RenderContext describes the capabilities that are available, presumably what fonts are available in this context, but could also include other things (can't kern, can't do letter-spacing, can't stretch text, etc). AFAICT, PDF and PostScript use the same RenderContext, but if there are differences, then they can each have their own. Once these capabilities are defined, they must be considered as the FOTree is built, and as layout is performed. So, while the Font is always a constant, it needs to be filtered through the lens of the RenderContext before it can be used properly. That is probably why the Font stuff ended up in the Render classes. And that is (part of) why I think, as FOP grows up here, it is important to distinguish between the Renderer and the RenderContext. java.awt.font.FontRenderContext performs this function for 2D font rendering. The arguments to the constructor are the AffineTransform for scaling typographical points to renderer pixels, and the booleans isAntiAliased and usesFractionalMetrics. If you'll give me a few weeks, I hope to be able to show you what I seem unable to sell with words. It will be good to see what you come up with. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Fonts
I have been exploring the way fonts are handled by Java as part of setting up a Java layout engine and renderer. I have committed a new class - org.apache.fop.render.awt.fonts - as a first cut at a fonts database for this application. I will attach the class description to this email. The focus of the Fonts class is to provide the facilities required by the Recommendation. The Rec and the CSS2 spec talk about the User Agent having a database of known fonts, and the new class is a sketch of this requirement. The work is far from complete, but out of the WIP the lines of an interface for such a fonts database start to emerge, for me at least. The database must be able to match a font given family name style - normal, italic, oblique variant - normal, small-caps weight - normal, bold, lighter, bolder, 100 - 900 stretch - ultra-condensed - ultra-expanded size Java font handling can match on family name, style and size directly and, with the fonts commonly available, on variant, weight and stretch only by constructing virtual fonts. The database must be able to provide a complete set of selectors for each of the system-fonts caption, icon, menu, message-box, small-caption, status-bar. Given the scope for the User Agent here, Java font handling can manage this. The database must support the generic font families serif, sans-serif, monospace, cursive and fantasy. This requirement is both system and installation dependent, but serif, sans-serif and monospace are available as logical fonts in Java. Cursive and fantasy fonts support will depend on available fonts, but individual renderers can check for the availability of a number of fonts known to fall into these categories. I have read again the Wiki page on the font subsystem in the light of my current work with Java fonts. I'm afraid that I am still convinced that font handling is properly the preserve of the renderers. The layout engine needs only the font metrics, even for Java-based layout. As far as layout is concerned, the glyphs could all be Wingdings, as long as the metrics are right. The other required information is that relating to font selection, as discussed above. The logical home for font selection information is the renderer. This is not to say that, once a clean fonts interface has been developed and implemented in all of the renderers, a further level of abstraction cannot be applied to bring all of the information under one umbrella. However, consider the problem of creating a new renderer. Fonts are inherently renderer specific. It may be that those fonts are shared between more that one renderer, but that fact is incidental to, e.g., the common ancestry of PS and PDF. Which is more sensible - writing a renderer's font handling to a common renderer font interface as an integral part of the renderer implementation, or discovering the fonts quirks of this particular renderer and adding them separately to a central font handler/registry? I'll try attaching the Javadoc description from org.apache.fop.render.awt.Fonts, as the included HTML may cause problems otherwise. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html Java font selection is based on family names. It seems that Java handles font mapping something like this:br Given a set of physical fonts like, e.g., Arial, Java reports them as pre font face: Arial logical:Arial family:Arial PSName:ArialMT Style: PLAIN FAMILY WEIGHT POSTURE SIZE TRANSFORM font face: Arial Cursiva logical:Arial Cursiva family:Arial PSName:Arial-ItalicMT Style: PLAIN FAMILY WEIGHT POSTURE SIZE TRANSFORM font face: Arial Negreta logical:Arial Negreta family:Arial PSName:Arial-BoldMT Style: PLAIN FAMILY WEIGHT POSTURE SIZE TRANSFORM font face: Arial Negreta cursiva logical:Arial Negreta cursiva family:Arial PSName:Arial-BoldItalicMT Style: PLAIN FAMILY WEIGHT POSTURE SIZE TRANSFORM /pre There are other Arial forms, e.g. Arial Black and Arial Narrow, but they fall into different families, as indicated by the font name. java.awt.font.TextAttribute defines a number of TextAttribute constants, and querying a Font object via getAvailableAttributes() will provide an array of attributes available on the Font. pIt seems there is a common set available on both Type1 and TrueType fonts in 1.4.2; viz FAMILY, WEIGHT, POSTURE, SIZE and TRANSFORM. Note that style is reported as PLAIN on all fonts, irrespective of the actual style according to the font name. pSIZE works as one might expect. WEIGHT is supported directly only for the weights provided in the set of family fonts. In the case of Arial, only REGULAR and BOLD. The same is true of POSTURE: REGULAR and OBLIQUE. There seems to be room here to experiment with virtual fonts. A virtual Arial font might be constructed
Re: Fonts
(Far from being an expert on fonts, but commenting anyway... ;)
Peter B. West wrote:
I have read again the Wiki page on the font subsystem in the light of
my current work with Java fonts. I'm afraid that I am still convinced
that font handling is properly the preserve of the renderers. The
layout engine needs only the font metrics, even for Java-based
layout. As far as layout is concerned, the glyphs could all be
Wingdings, as long as the metrics are right. The other required
information is that relating to font selection, as discussed above.
The logical home for font selection information is the renderer.
I see no problem with this. Ideally, anything renderer-specific,
including fonts, should be in the appropriate fop.render.{rendertype}
package.
This is not to say that, once a clean fonts interface has been
developed and implemented in all of the renderers, a further level of
abstraction cannot be applied to bring all of the information under
one umbrella. However, consider the problem of creating a new
renderer. Fonts are inherently renderer specific. It may be that
those fonts are shared between more that one renderer, but that fact
is incidental to, e.g., the common ancestry of PS and PDF.
If any render type relies on the fonts of another render type (e.g. PS
using PDF), we can have it import or subclass the font libraries of that
render type. (E.g. render.ps. code would import, say,
render.pdf.font.xxx classes.) The dependencies are better
self-documenting that way, IMO.
Which is more sensible - writing a renderer's font handling to a
common renderer font interface as an integral part of the renderer
implementation, or discovering the fonts quirks of this particular
renderer and adding them separately to a central font handler/registry?
The latter is outside my scope of knowledge (but sounds messy ;)--as for
the former, what font-specific methods (and their signatures) do you see
us needing to add to our render.Render interface (which declares the
minimal methods needed by layout to interact with a renderer)?
getFontMetrics()? isFontSupported()? (Currently, there is just a
setupFontInfo() in this interface, which, as you say, seems
nonideal--layout feeding the renderers the FontInfo.)
Thanks,
Glen
Re: Fonts
Glen Mazza wrote:
(Far from being an expert on fonts, but commenting anyway... ;)
Peter B. West wrote:
I have read again the Wiki page on the font subsystem in the light of
my current work with Java fonts. I'm afraid that I am still convinced
that font handling is properly the preserve of the renderers. The
layout engine needs only the font metrics, even for Java-based
layout. As far as layout is concerned, the glyphs could all be
Wingdings, as long as the metrics are right. The other required
information is that relating to font selection, as discussed above.
The logical home for font selection information is the renderer.
I see no problem with this. Ideally, anything renderer-specific,
including fonts, should be in the appropriate fop.render.{rendertype}
package.
This is not to say that, once a clean fonts interface has been
developed and implemented in all of the renderers, a further level of
abstraction cannot be applied to bring all of the information under
one umbrella. However, consider the problem of creating a new
renderer. Fonts are inherently renderer specific. It may be that
those fonts are shared between more that one renderer, but that fact
is incidental to, e.g., the common ancestry of PS and PDF.
If any render type relies on the fonts of another render type (e.g. PS
using PDF), we can have it import or subclass the font libraries of that
render type. (E.g. render.ps. code would import, say,
render.pdf.font.xxx classes.) The dependencies are better
self-documenting that way, IMO.
This seems to be the pivot around which both approaches can coalesce.
As I look at this for longer, I see that my initial notions about the
requirement for fonts are compatible with the generics that Jeremias and
Victor are working towards. Those are, it seems to me, a set of
handlers for different types of Fonts - Type 1, TrueType, OpenType,
Metafont, Framemaker fonts, whatever.
Which is more sensible - writing a renderer's font handling to a
common renderer font interface as an integral part of the renderer
implementation, or discovering the fonts quirks of this particular
renderer and adding them separately to a central font handler/registry?
The latter is outside my scope of knowledge (but sounds messy ;)--as for
the former, what font-specific methods (and their signatures) do you see
us needing to add to our render.Render interface (which declares the
minimal methods needed by layout to interact with a renderer)?
getFontMetrics()? isFontSupported()? (Currently, there is just a
setupFontInfo() in this interface, which, as you say, seems
nonideal--layout feeding the renderers the FontInfo.)
At the moment, I don't see any font-specific methods required. The
basic methods are
FopFont getFont(String family, enum style, enum variant, enum
weight, enum stretch, float size, enum selectionStrategy);
FopFont getGenericFont(enum type. enum style, enum variant,
enum weight, enum stretch, float size);
FopFont getSystemFont(enum type);
where enum is probably an int in all cases. selectionStrategy
determines whether, e.g., intelligent font substitution occurs if the
family doesn't have an exact match.
Individual renderers would access their own databases of available
fonts, and make their own decisions about what comprises a generic font,
what comprises a system font, and how to build virtual fonts if
necessary. This functionality within the renderers could be built on
top of the Type1, TrueType, etc. versions of FopFont. However,
individual renderers may need to vary the outcomes. For example, PDF,
although it uses Type1 and TrueType fonts, needs to express them
somewhat differently. Consider that a throw-away comment; I don't know
how PDF uses these font types.
Take the Java renderer. By including appendedfontpath in a new or
modified font.properties file, I can add new Type 1 or TrueType fonts to
the JVM. Let's say I find a Garamond font when I start up. Does it
qualify as a serif font? As a fantasy font? That sort of information
can be built into the relevant underlying font handler, but I can see
that individual renderers might want to override some methods in order
to make their own Quality Of Service decisions. See the Note under
auto in 7.8.3 font-selection-strategy in the 1.1 Draft.
What I have said qualifies as a central font registry in a loose
sense, which may be refined later. E.g., QoS information may
progressively be moved into the underlying font type handlers. However,
it seems to me that the final decision is with the renderer, and it is
the renderer that should be queried when the FO tree is being built and
fonts resolved.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
RE: Fonts
Peter B. West wrote: I have been exploring the way fonts are handled by Java as part of setting up a Java layout engine and renderer. I have committed a new class - org.apache.fop.render.awt.fonts - as a first cut at a fonts database for this application. I will attach the class description to this email. The last time I checked, there was no way to get to the physical font file through the awt interface. It is possible that java.awt.font.OpenType can provide some or all of what is needed for TTF and OT fonts, but I don't know of a way to handle Type1 embedding at all. This means that you cannot ever embed the said font, unless you set up a parallel system (similar to the way FOP handles things now) to find the physical file. Another issue is headless environments. I once went down the path of trying to figure out how to register fonts in a headless environment, and frankly don't remember what I learned. It is probably possible. There may come a time when the awt system is the way to go, but AFAICT, it isn't here yet, but I'll be glad to be proven wrong. I don't say this to discourage you -- if you know how to make it work, that will be a very good thing. BTW, Hansuli Anderegg has been a frequent advocate of the awt system for this work. One important point here is that, even if awt font handling were the correct *implementation* of font handling to use, there would still be, IMO anyway, utility in hiding even that fact from the rest of FOP, certainly no harm. I am taking the next comment out of sequence from Peter's original post, because it is fundamental to comments earlier in his post, which I will address below: Fonts are inherently renderer specific. It may be that those No. Font *embedding* is renderer specific. AFAICT, everything else about the font is the same. I have read again the Wiki page on the font subsystem in the light of my current work with Java fonts. I'm afraid that I am still convinced that font handling is properly the preserve of the renderers. The layout engine needs only the font metrics, even for Java-based layout. As far as layout is concerned, the glyphs could all be Wingdings, as long as the metrics are right. The other required information is that relating to font selection, as discussed above. The logical home for font selection information is the renderer. It is a non sequiter to say that layout needs only font metrics (which is true), and therefore the logical home for font selection information is the renderer. One thing that may be confusing you is the distinction that awt makes between java.awt.Font and java.awt.FontMetrics. There is only one constructor for FontMetrics: protected FontMetrics(Font font) Therefore, at a *logical* level, there is a one-to-one relationship between the two. At the physical file level there is also a strict one-to-one relationship between the two, when the metrics are separated at all. There is no need that I can see for FOP to treat the concepts of Font and FontMetric as two different things. Once a font object is stored in the FOTree that object should be able to return any metrics information about that font. This is not to say that, once a clean fonts interface has been developed and implemented in all of the renderers, a further level of abstraction cannot be applied to bring all of the information under one umbrella. I have always found that cleaning up the abstraction levels and interfaces (i.e. getting the big-picture stuff straight first) makes getting the details right easier as well, by isolating them. However, I won't quibble with you. However, consider the problem of creating a new renderer. Fonts are inherently renderer specific. It may be that those fonts are shared between more that one renderer, but that fact is incidental to, e.g., the common ancestry of PS and PDF. Which is more sensible - writing a renderer's font Again, the underlying font is the same whether you are rendering to PDF, Postscript, or anything else. Only the embedding would change. Please let me know if I have missed something. PDF. Which is more sensible - writing a renderer's font handling to a common renderer font interface as an integral part of the renderer implementation, or discovering the fonts quirks of this particular renderer and adding them separately to a central font handler/registry? This is a very good question, one that I have already pondered at some length. Again, I am thinking only of the process of embedding here. The first principle that I look to is that in either case, font embedding should be factored out of FOP. There is nothing about either font-handling or the creation of PDF files (or PostScript, or PCL, or whatever) that is FOP-specific. Assuming this, I would lean heavily toward placing the font-embedding logic in the output-specific library (i.e., put the PDF embedding logic into the pdf output library, instead of fonts), because
DO NOT REPLY [Bug 28705] New: - PDF Text search doesnt work for embedded fonts.
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=28705. 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=28705 PDF Text search doesnt work for embedded fonts. Summary: PDF Text search doesnt work for embedded fonts. Product: Fop Version: 0.20.5 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Enhancement Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am using FOP for PDF rendering and using Arial.xml and Arialbd.xml (metrics file) for embedding the Arial and Arial Bold font. The FOP generates PDF correctly but the content with embedded font is not searachable.
DO NOT REPLY [Bug 28705] - PDF Text search doesnt work for embedded fonts.
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=28705. 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=28705 PDF Text search doesnt work for embedded fonts. --- Additional Comments From [EMAIL PROTECTED] 2004-04-30 08:30 --- This is a known issue. You can work around it in some cases, depending on the glyphs you are using in the Font. If you specify the -enc ansi option when generating the metrics files, copy, paste and search operations will work in PDF if you are only using characters in a very limited character set; I think this is iso-8859-1, but not absolutely certain.
cvs commit: xml-fop/src/java/org/apache/fop/fonts FontInfo.java
gmazza 2004/04/21 16:08:51
Added: src/java/org/apache/fop/fonts FontInfo.java
Log:
New FontInfo class (original design was from Layout.FontInfo, and was removed
and placed into the Document class last year). This class is to be an encapsulation
of the Font information within apps.Document, also to be used in Transcoder and other
non-XSL-specific classes and packages instead of an apps.Document object, in those
cases where the latter either presents too much information and/or is not relevant
for referenced class' task. Currently not used, pending new patch in Bugzilla.
Revision ChangesPath
1.1 xml-fop/src/java/org/apache/fop/fonts/FontInfo.java
Index: FontInfo.java
===
/*
* Copyright 2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
/* $Id: FontInfo.java,v 1.1 2004/04/21 23:08:51 gmazza Exp $ */
package org.apache.fop.fonts;
// Java
import java.util.Map;
/**
* The FontInfo for the layout and rendering of a fo document.
* This stores the list of available fonts that are setup by
* the renderer. The font name can be retrieved for the
* family style and weight.
* br
* Currently font supported font-variant small-caps is not
* implemented.
*/
public class FontInfo {
/** Map containing fonts that have been used */
private Map usedFonts;
/** look up a font-triplet to find a font-name */
private Map triplets;
/** look up a font-name to get a font (that implements FontMetrics at least) */
private Map fonts;
/**
* Main constructor
*/
public FontInfo() {
this.triplets = new java.util.HashMap();
this.fonts = new java.util.HashMap();
this.usedFonts = new java.util.HashMap();
}
/**
* Checks if the font setup is valid (At least the ultimate fallback font
* must be registered.)
* @return True if valid
*/
public boolean isSetupValid() {
return triplets.containsKey(Font.DEFAULT_FONT);
}
/**
* Adds a new font triplet.
* @param name internal key
* @param family font family name
* @param style font style (normal, italic, oblique...)
* @param weight font weight
*/
public void addFontProperties(String name, String family, String style,
int weight) {
/*
* add the given family, style and weight as a lookup for the font
* with the given name
*/
String key = createFontKey(family, style, weight);
this.triplets.put(key, name);
}
/**
* Adds font metrics for a specific font.
* @param name internal key
* @param metrics metrics to register
*/
public void addMetrics(String name, FontMetrics metrics) {
// add the given metrics as a font with the given name
this.fonts.put(name, metrics);
}
/**
* Lookup a font.
* br
* Locate the font name for a given family, style and weight.
* The font name can then be used as a key as it is unique for
* the associated document.
* This also adds the font to the list of used fonts.
* @param family font family
* @param style font style
* @param weight font weight
* @return internal key
*/
public String fontLookup(String family, String style,
int weight) {
String key;
// first try given parameters
key = createFontKey(family, style, weight);
String f = (String)triplets.get(key);
if (f == null) {
// then adjust weight, favouring normal or bold
f = findAdjustWeight(family, style, weight);
// then try any family with orig weight
if (f == null) {
key = createFontKey(any, style, weight);
f = (String)triplets.get(key);
}
// then try any family with adjusted weight
if (f == null) {
f = findAdjustWeight(family, style, weight);
}
// then use default
if (f == null) {
f = (String
cvs commit: xml-fop/src/java/org/apache/fop/fonts Typeface.java MultiByteFont.java Font.java LazyFont.java SingleByteFont.java
jeremias2004/04/03 05:31:40
Modified:src/java/org/apache/fop/fonts Typeface.java
MultiByteFont.java Font.java LazyFont.java
SingleByteFont.java
Log:
New function to determine whether a particular character is available for this font.
Revision ChangesPath
1.3 +8 -1 xml-fop/src/java/org/apache/fop/fonts/Typeface.java
Index: Typeface.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/Typeface.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Typeface.java 27 Feb 2004 17:47:14 - 1.2
+++ Typeface.java 3 Apr 2004 13:31:40 - 1.3
@@ -40,6 +40,13 @@
public abstract char mapChar(char c);
/**
+ * Determines whether this font contains a particular character/glyph.
+ * @param c character to check
+ * @return True if the character is supported, Falso otherwise
+ */
+public abstract boolean hasChar(char c);
+
+/**
* Determines whether the font is a multibyte font.
* @return True if it is multibyte
*/
1.6 +22 -12xml-fop/src/java/org/apache/fop/fonts/MultiByteFont.java
Index: MultiByteFont.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/MultiByteFont.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- MultiByteFont.java27 Feb 2004 17:47:14 - 1.5
+++ MultiByteFont.java3 Apr 2004 13:31:40 - 1.6
@@ -125,12 +125,7 @@
* @see org.apache.fop.fonts.FontDescriptor#isEmbeddable()
*/
public boolean isEmbeddable() {
-if (getEmbedFileName() == null
- embedResourceName == null) {
-return false;
-} else {
-return true;
-}
+return !(getEmbedFileName() == null embedResourceName == null);
}
/**
@@ -196,20 +191,27 @@
}
*/
-/**
- * @see org.apache.fop.fonts.Font#mapChar(char)
- */
-public char mapChar(char c) {
+private int findGlyphIndex(char c) {
int idx = (int)c;
int retIdx = 0;
for (int i = 0; (i bfentries.length) retIdx == 0; i++) {
if (bfentries[i].getUnicodeStart() = idx
bfentries[i].getUnicodeEnd() = idx) {
-retIdx = bfentries[i].getGlyphStartIndex() + idx
- - bfentries[i].getUnicodeStart();
+
+retIdx = bfentries[i].getGlyphStartIndex()
++ idx
+- bfentries[i].getUnicodeStart();
}
}
+return retIdx;
+}
+
+/**
+ * @see org.apache.fop.fonts.Typeface#mapChar(char)
+ */
+public char mapChar(char c) {
+int retIdx = findGlyphIndex(c);
if (isEmbeddable()) {
// Reencode to a new subset font or get
@@ -230,6 +232,14 @@
return (char)retIdx;
}
+
+/**
+ * @see org.apache.fop.fonts.Typeface#hasChar(char)
+ */
+public boolean hasChar(char c) {
+return (findGlyphIndex(c) 0);
+}
+
/**
* Sets the bfentries.
1.7 +18 -2 xml-fop/src/java/org/apache/fop/fonts/Font.java
Index: Font.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/Font.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- Font.java 27 Feb 2004 17:47:14 - 1.6
+++ Font.java 3 Apr 2004 13:31:40 - 1.7
@@ -154,6 +154,20 @@
return c;
}
+
+/**
+ * Determines whether this font contains a particular character/glyph.
+ * @param c character to check
+ * @return True if the character is supported, Falso otherwise
+ */
+public boolean hasChar(char c) {
+if (metric instanceof org.apache.fop.fonts.Typeface) {
+return ((org.apache.fop.fonts.Typeface)metric).hasChar(c);
+} else {
+// Use default CodePointMapping
+return (CodePointMapping.getMapping(WinAnsiEncoding).mapChar(c) 0);
+}
+}
/**
* @see java.lang.Object#toString()
@@ -182,7 +196,6 @@
* This also performs some guessing on widths on various
* versions of space that might not exists in the font.
* @param c character to inspect
- * @param fs FontState to use
* @return the width of the character
*/
public int getCharWidth(char c) {
@@ -257,10 +270,13 @@
/**
* Calculates the word
cvs commit: xml-fop/src/java/org/apache/fop/fonts/truetype TTFFile.java
jeremias2004/04/02 01:15:10
Modified:src/java/org/apache/fop/fonts/truetype TTFFile.java
Log:
Changed logging to use static loggers from Jakarta Commons Logging (via
LogFactory).
Revision ChangesPath
1.7 +54 -94xml-fop/src/java/org/apache/fop/fonts/truetype/TTFFile.java
Index: TTFFile.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/truetype/TTFFile.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- TTFFile.java 31 Mar 2004 10:55:06 - 1.6
+++ TTFFile.java 2 Apr 2004 09:15:10 - 1.7
@@ -23,8 +23,8 @@
import java.util.Map;
import java.util.List;
-import org.apache.commons.logging.impl.SimpleLog;
import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
import org.apache.fop.fonts.Glyphs;
/**
@@ -70,7 +70,7 @@
/**
* Contains glyph data
*/
-protected TTFMtxEntry mtxTab[]; // Contains glyph data
+protected TTFMtxEntry[] mtxTab; // Contains glyph data
private int[] mtxEncoded = null;
private String fontName = ;
@@ -94,7 +94,7 @@
private short lastChar = 0;
-private int ansiWidth[];
+private int[] ansiWidth;
private Map ansiIndex;
private TTFDirTabEntry currentDirTab;
@@ -102,23 +102,7 @@
/**
* logging instance
*/
-protected Log logger = null;
-
-/**
- * Sets the Commons-Logging instance for this class
- * @param logger The Commons-Logging instance
- */
-public void setLogger(Log logger) {
-this.logger = logger;
-}
-
-/**
- * Returns the Commons-Logging instance for this class
- * @return The Commons-Logging instance
- */
-protected Log getLogger() {
-return logger;
-}
+protected Log log = LogFactory.getLog(TTFFile.class);
/**
* Position inputstream to position indicated
@@ -128,9 +112,7 @@
long offset) throws IOException {
TTFDirTabEntry dt = (TTFDirTabEntry)dirTabs.get(name);
if (dt == null) {
-if (logger != null) {
-logger.error(Dirtab + name + not found.);
-}
+log.error(Dirtab + name + not found.);
} else {
in.seekSet(dt.getOffset() + offset);
this.currentDirTab = dt;
@@ -175,9 +157,7 @@
int numCMap = in.readTTFUShort();// Number of cmap subtables
long cmapUniOffset = 0;
-if (logger != null) {
-logger.info(numCMap + cmap tables);
-}
+log.info(numCMap + cmap tables);
//Read offset for all tables. We are only interested in the unicode table
for (int i = 0; i numCMap; i++) {
@@ -185,10 +165,7 @@
int cmapEID = in.readTTFUShort();
long cmapOffset = in.readTTFULong();
-if (logger != null) {
-logger.debug(Platform ID: + cmapPID
-+ Encoding: + cmapEID);
-}
+log.debug(Platform ID: + cmapPID + Encoding: + cmapEID);
if (cmapPID == 3 cmapEID == 1) {
cmapUniOffset = cmapOffset;
@@ -196,10 +173,8 @@
}
if (cmapUniOffset = 0) {
-if (logger != null) {
-logger.fatal(Unicode cmap table not present);
-logger.fatal(Unsupported format: Aborting);
-}
+log.fatal(Unicode cmap table not present);
+log.fatal(Unsupported format: Aborting);
return false;
}
@@ -208,9 +183,7 @@
int cmapFormat = in.readTTFUShort();
/*int cmap_length =*/ in.readTTFUShort(); //skip cmap length
-if (logger != null) {
-logger.info(CMAP format: + cmapFormat);
-}
+log.info(CMAP format: + cmapFormat);
if (cmapFormat == 4) {
in.skip(2);// Skip version number
@@ -219,18 +192,18 @@
int cmapEntrySelector = in.readTTFUShort();
int cmapRangeShift = in.readTTFUShort();
-if (logger != null logger.isDebugEnabled()) {
-logger.debug(segCountX2 : + cmapSegCountX2);
-logger.debug(searchRange : + cmapSearchRange);
-logger.debug(entrySelector: + cmapEntrySelector);
-logger.debug(rangeShift : + cmapRangeShift);
+if (log.isDebugEnabled()) {
+log.debug(segCountX2 : + cmapSegCountX2);
+log.debug(searchRange : + cmapSearchRange);
+log.debug(entrySelector: + cmapEntrySelector
cvs commit: xml-fop/src/java/org/apache/fop/fonts/type1 PFMFile.java
jeremias2004/04/02 01:15:16
Modified:src/java/org/apache/fop/fonts/type1 PFMFile.java
Log:
Changed logging to use static loggers from Jakarta Commons Logging (via
LogFactory).
Revision ChangesPath
1.7 +9 -25 xml-fop/src/java/org/apache/fop/fonts/type1/PFMFile.java
Index: PFMFile.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/type1/PFMFile.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- PFMFile.java 31 Mar 2004 10:55:06 - 1.6
+++ PFMFile.java 2 Apr 2004 09:15:16 - 1.7
@@ -25,6 +25,7 @@
import org.apache.commons.io.IOUtils;
import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
// FOP
@@ -65,24 +66,7 @@
/**
* logging instance
*/
-protected Log logger = null;
-
-
-/**
- * Sets the Commons-Logging instance for this class
- * @param logger The Commons-Logging instance
- */
-public void setLogger(Log logger) {
-this.logger = logger;
-}
-
-/**
- * Returns the Commons-Logging instance for this class
- * @return The Commons-Logging instance
- */
-protected Log getLogger() {
-return logger;
-}
+protected Log log = LogFactory.getLog(PFMFile.class);
/**
* Parses a PFM file
@@ -97,7 +81,7 @@
/*final int version =*/ in.readShort();
final long filesize = in.readInt();
if (filesize != buf.length) {
-logger.warn(Effective file size is not the same as indicated in the
header.);
+log.warn(Effective file size is not the same as indicated in the
header.);
}
bufin.reset();
@@ -142,7 +126,7 @@
private void loadExtension(PFMInputStream inStream) throws IOException {
final int size = inStream.readShort();
if (size != 30) {
-logger.warn(Size of extension block was expected to be
+log.warn(Size of extension block was expected to be
+ 30 bytes, but was + size + bytes.);
}
final long extMetricsOffset = inStream.readInt();
@@ -184,7 +168,7 @@
int i = inStream.readShort();
-logger.info(i + kerning pairs);
+log.info(i + kerning pairs);
while (i 0) {
int g1 = (int)inStream.readByte();
i--;
@@ -195,12 +179,12 @@
if (adj 0x8000) {
adj = -(0x1 - adj);
}
-logger.debug(Char no: ( + g1 + , + g2 + ) kern: + adj);
+log.debug(Char no: ( + g1 + , + g2 + ) kern: + adj);
-if (logger.isDebugEnabled()) {
+if (log.isDebugEnabled()) {
final String glyph1 = Glyphs.TEX8R_GLYPH_NAMES[g1];
final String glyph2 = Glyphs.TEX8R_GLYPH_NAMES[g2];
-logger.debug(glyphs: + glyph1 + , + glyph2);
+log.debug(glyphs: + glyph1 + , + glyph2);
}
Map adjTab = (Map)kerningTab.get(new Integer(g1));
@@ -220,7 +204,7 @@
private void loadExtMetrics(PFMInputStream inStream) throws IOException {
final int size = inStream.readShort();
if (size != 52) {
-logger.warn(Size of extension block was expected to be
+log.warn(Size of extension block was expected to be
+ 52 bytes, but was + size + bytes.);
}
inStream.skip(12); //Skip etmPointSize, etmOrientation, etmMasterHeight,
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/fonts/apps TTFReader.java PFMReader.java
jeremias2004/04/02 01:16:12
Modified:src/java/org/apache/fop/fonts/apps TTFReader.java
PFMReader.java
Log:
Changed logging to use static loggers from Jakarta Commons Logging (via
LogFactory).
Changed the way Commons Logging is set up.
Some touch-up in the code.
Revision ChangesPath
1.5 +60 -65xml-fop/src/java/org/apache/fop/fonts/apps/TTFReader.java
Index: TTFReader.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/apps/TTFReader.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- TTFReader.java31 Mar 2004 10:55:06 - 1.4
+++ TTFReader.java2 Apr 2004 09:16:12 - 1.5
@@ -31,15 +31,14 @@
import org.w3c.dom.Document;
import org.w3c.dom.Element;
-import org.apache.commons.logging.impl.SimpleLog;
import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
//FOP
+import org.apache.fop.apps.Version;
import org.apache.fop.fonts.truetype.FontFileReader;
import org.apache.fop.fonts.truetype.TTFCmapEntry;
import org.apache.fop.fonts.truetype.TTFFile;
-import org.apache.commons.logging.Log;
-
/**
* A tool which reads TTF files and generates
@@ -50,23 +49,7 @@
/**
* logging instance
*/
-protected Log logger = null;
-
-/**
- * Sets the Commons-Logging instance for this class
- * @param logger The Commons-Logging instance
- */
-public void setLogger(Log logger) {
-this.logger = logger;
-}
-
-/**
- * Returns the Commons-Logging instance for this class
- * @return The Commons-Logging instance
- */
-protected Log getLogger(Log logger) {
-return logger;
-}
+protected Log log = LogFactory.getLog(TTFReader.class);
/**
* Parse commandline arguments. put options in the HashMap and return
@@ -94,32 +77,31 @@
}
-private void displayUsage() {
-if (logger != null logger.isInfoEnabled()) {
-logger.info(
- java org.apache.fop.fonts.apps.TTFReader [options]
fontfile.ttf xmlfile.xml);
-logger.info( where options can be:);
-logger.info(-d DEBUG|INFO);
-logger.info( Set debug level (default: INFO).);
-logger.info(-enc ansi);
-logger.info( With this option you create a WinAnsi encoded font.);
-logger.info( The default is to create a CID keyed font.);
-logger.info( If you're not going to use characters outside the);
-logger.info( pdfencoding range (almost the same as iso-8889-1));
-logger.info( you can add this option.);
-logger.info(-ttcname fontname);
-logger.info( If you're reading data from a TrueType Collection);
-logger.info( (.ttc file) you must specify which font from the);
-logger.info( collection you will read metrics from. If you read);
-logger.info( from a .ttc file without this option, the fontnames);
-logger.info( will be listed for you.);
-logger.info( -fn fontname);
-logger.info( default is to use the fontname in the .ttf file,
but);
-logger.info( you can override that name to make sure that the);
-logger.info( embedded font is used (if you're embedding fonts));
-logger.info( instead of installed fonts when viewing documents );
-logger.info( with Acrobat Reader.);
-}
+private static void displayUsage() {
+System.out.println(
+java + TTFReader.class.getName() + [options] fontfile.ttf
xmlfile.xml);
+System.out.println();
+System.out.println(where options can be:);
+System.out.println(-d WARN|INFO|DEBUG);
+System.out.println(Set debug level (default: WARN).);
+System.out.println(-enc ansi);
+System.out.println(With this option you create a WinAnsi encoded
font.);
+System.out.println(The default is to create a CID keyed font.);
+System.out.println(If you're not going to use characters outside the);
+System.out.println(pdfencoding range (almost the same as iso-8889-1));
+System.out.println(you can add this option.);
+System.out.println(-ttcname fontname);
+System.out.println(If you're reading data from a TrueType Collection);
+System.out.println((.ttc file) you must specify which font from the);
+System.out.println(collection you will read metrics from. If you
read);
+System.out.println(from a .ttc file without this option
Re: Fonts and Document
(comments inline) On 17.03.2004 04:53:46 Peter B. West wrote: snip/ As you've seen the Document class is a central class in font handling. It currently (not in my ideas) provides direct access to font metric information and to the list of fonts actually used in a rendering run (we don't always want to embedd them all). The setup of all fonts is done in the FontSetup class where the base 14 fonts are defined. Additionally, custom fonts are added there. But the custom fonts are mostly renderer-dependant, so at the moment, some font setup also takes place in PDFRenderer for example. See PDFRenderer.configure (which can build custom font information using an Avalon Configuration object using a helper method from FontSetup) and PrintRenderer.setupFontInfo which actually triggers the font setup. The fonts get registered with the Document object and subsequently is available to the layout engine. One of the complications is that Document wears so many hats. I see a Document object referred to by the variable fontInfo in one place, and by the variable foTreeControl in another. Document implements FOTreeControl, FOTreeListener and AreaTreeControl, so the foTreeControl variable looks deliberate, but the fontInfo may be a hangover. In any case, wouldn't it be clearer to have such functions realized in separate objects which are created and managed by Document? I agree 100%. I don't particularly like the Document class right now. I'm still dreaming of font source services and an Avalon container but I don't see it happen in the near future. Most font classes in the fonts package deal with the different font formats (single byte und unicode, base und custom...). There's also a difference in audience: The layout needs different information (metrics in particular) than the renderers (primarily information for using and embedding the font in the target format. This is my first close look at fonts, and I have browsed the java.awt.Font and java.awt.FontMetrics classes and the java.awt.font package. In itself, this bundle of interfaces and classes is complex, but the nub of it seems to be the 2D font classes. At first glance, there is a close connection between fonts, glyphs, strings, text attributes and line layout, all covered in these classes. I am wondering if we cannot use the Java model as a basis for FOP's line area layout API. The discussion in http://java.sun.com/j2se/1.4.2/docs/guide/2d/spec/j2d-fonts.html#wp66677 contains a discussion of implementing a custom text layout mechanism to enable features like kerning and ligatures. We probably could, but I'm stating again that the whole AWT thing has its quirks and it has already grown over a few JDK versions. I'd rather have a clean cut tailored to our need with adapters for AWT fonts (the AWT font source) and a chance to support whatever fonts we want. Especially for embedding fonts (an important feature), last time I looked, AWT fonts did not provide the necessary infrastructure. My intention is to develop the initial alt-design layout using AWT rendering. I assumed that I could get usable testing output more quickly that way, without having to delve into PDF. Good idea but I'd like to point out something: If you look at Batik's Javadocs you'll see that there are several packages dealing with extending AWT infrastructure in order to meet the projects needs. Maybe we need to find out how we can profit from the Batik team's findings concerning AWT. Maybe parts of Batik could be used to work around some of AWT's problems when they show up. There it is again, the XML Graphics umbrella. Now, if you base your layout on AWT APIs and find out later that for PDF and PS the infrastructure is not good enough, you'll have a problem but I don't think that's dramatic. It shouldn't be all to hard to rewrite the necessary parts then, to draw in a adapterish abstraction layer. My comments may simply be conditioned by that perception. I'm not talking about adopting 1.4 (and 1.5 when it is stable), but using the API model where it provides appropriate methods for laying out text. One implication of that would be a fairly intricate interaction between all the phases of FOP, involving the font details provided by the renderer. However, I recall that Hansuli Anderegg has been working along these lines for some time now. Right, I've done some investigation myself in this area by creating proof-of-concept JPS output handlers to create PDF and PS (using parts of our transcoders, i.e. the Graphics2D implementations). However, I still don't buy the idea, yet, as the way to go. With separate PDF and PS renderers I have everything under control. More code, granted. It would certainly be interesting to have both models and compare them more closely. I have once looked at Hansuli's code which seemed to me a modified copy of the AWT renderer which is not such a good thing to do
Re: Fonts and Document
On Wed, Mar 17, 2004 at 09:21:03AM +0800, Manuel Mall wrote: Simon, tried the URL you gave (http://www.leverkruid.nl/FOP/documentation.xml) and got the error (IE 6): The system cannot locate the object specified. Error processing resource 'http://www.leverkruid.nl/FOP/docbookx.dtd'. The XML file is not meant to be viewed in the browser. If you try to do that, the browser searches for the DTD because the document lists one in its DOCTYPE declaration. And that DTD is not provided by my web page. If you would have the DTD that would not help you because there is no stylesheet associated with the XML file. The docbook stylesheets are too large and complicated to be applied by a browser. You can only save the XML file and apply XSL stylesheets to obtain an xhtml or pdf file. Mozilla Firefox fails as well. Same reason. Regards, Simon Pepping -- Simon Pepping home page: http://www.leverkruid.nl
Re: Fonts and Document
On Mon, Mar 15, 2004 at 01:40:59PM -0800, Clay Leeds wrote: On Mar 15, 2004, at 1:15 PM, Simon Pepping wrote: Looks good, Simon... I don't suppose you could create a PDF version? (I know a great XML = PDF conversion tool. :-)) Seriously though, this looks like a great potential addition to the Developer documentation we have on the FOP site. BTW, it looks like everything after Chapter 2, #3 is under PRE or CODE tags, so you've lost the formatting. I am glad you like it. I do not see your problem after Chapter 2, #3. In my browser, Mozilla and Mozilla FireBird viewing the local file (i.e. not via a server), everything looks as I expect. I will try this great conversion tool. If it can deal with the fo file that is produced by the Docbook XSL style sheets, it should be easy. You can try it yourself, because the DocBook XML file is also available from my web site, http://www.leverkruid.nl/FOP/documentation.xml. I am currently converting my raw notes to DocBook XML, and in the process rewrite those portions that do not seem good enough. I hope to finish this in two to four weeks. I would be pleased to add it to the developer documentation on the FOP web site if it is appreciated. I wonder if DocBook XML is the right format for the web site. For me it is the right format to write this kind of technical documentation. Regards, Simon Pepping -- Simon Pepping home page: http://www.leverkruid.nl
RE: Fonts and Document
Simon, tried the URL you gave (http://www.leverkruid.nl/FOP/documentation.xml) and got the error (IE 6): The system cannot locate the object specified. Error processing resource 'http://www.leverkruid.nl/FOP/docbookx.dtd'. Mozilla Firefox fails as well. Manuel
Re: Fonts and Document
Jeremias, See below... Jeremias Maerki wrote: The font subsystem is still far from finished. It's still quite complex to understand, unnecessarily so IMO. My font source idea still need to be implemented... Let's see if I can pull together some connectors. I agree that it is complex to understand. As you've seen the Document class is a central class in font handling. It currently (not in my ideas) provides direct access to font metric information and to the list of fonts actually used in a rendering run (we don't always want to embedd them all). The setup of all fonts is done in the FontSetup class where the base 14 fonts are defined. Additionally, custom fonts are added there. But the custom fonts are mostly renderer-dependant, so at the moment, some font setup also takes place in PDFRenderer for example. See PDFRenderer.configure (which can build custom font information using an Avalon Configuration object using a helper method from FontSetup) and PrintRenderer.setupFontInfo which actually triggers the font setup. The fonts get registered with the Document object and subsequently is available to the layout engine. One of the complications is that Document wears so many hats. I see a Document object referred to by the variable fontInfo in one place, and by the variable foTreeControl in another. Document implements FOTreeControl, FOTreeListener and AreaTreeControl, so the foTreeControl variable looks deliberate, but the fontInfo may be a hangover. In any case, wouldn't it be clearer to have such functions realized in separate objects which are created and managed by Document? Most font classes in the fonts package deal with the different font formats (single byte und unicode, base und custom...). There's also a difference in audience: The layout needs different information (metrics in particular) than the renderers (primarily information for using and embedding the font in the target format. This is my first close look at fonts, and I have browsed the java.awt.Font and java.awt.FontMetrics classes and the java.awt.font package. In itself, this bundle of interfaces and classes is complex, but the nub of it seems to be the 2D font classes. At first glance, there is a close connection between fonts, glyphs, strings, text attributes and line layout, all covered in these classes. I am wondering if we cannot use the Java model as a basis for FOP's line area layout API. The discussion in http://java.sun.com/j2se/1.4.2/docs/guide/2d/spec/j2d-fonts.html#wp66677 contains a discussion of implementing a custom text layout mechanism to enable features like kerning and ligatures. My intention is to develop the initial alt-design layout using AWT rendering. I assumed that I could get usable testing output more quickly that way, without having to delve into PDF. My comments may simply be conditioned by that perception. I'm not talking about adopting 1.4 (and 1.5 when it is stable), but using the API model where it provides appropriate methods for laying out text. One implication of that would be a fairly intricate interaction between all the phases of FOP, involving the font details provided by the renderer. However, I recall that Hansuli Anderegg has been working along these lines for some time now. Btw, what search keys should I use to recover details of your font model from the archive, assuming there are differences between your model and the wiki? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
DO NOT REPLY [Bug 27727] New: - problem displaying Japanese fonts in PDF.
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=27727. 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=27727 problem displaying Japanese fonts in PDF. Summary: problem displaying Japanese fonts in PDF. Product: Fop Version: 0.15 Platform: HP OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have a problem while rendering XML containing unicode characters into japanese characters. I am working on Weblogic 8.1 on NT OS. When the font file(Msmincho.ttf) is placed in c:/winnt/fonts directory the rendering works fine and pdf is generated with Japanese Characters. But when the ttf file is place in a different folder I get the following exception even though I have made an entry in basedir element of userconfig file. java.lang.NullPointerException at org.apache.fop.render.pdf.fonts.LazyFont.getAscender(LazyFont.java:82) at org.apache.fop.layout.FontState.getAscender(FontState.java:56) at org.apache.fop.layout.LineArea.init(LineArea.java:111) at org.apache.fop.layout.BlockArea.start(BlockArea.java:181) at org.apache.fop.fo.flow.Block.layout(Block.java:251) at org.apache.fop.fo.flow.TableCell.layout(TableCell.java:269) at org.apache.fop.fo.flow.TableRow.layout(TableRow.java:344) at org.apache.fop.fo.flow.TableBody.layout(TableBody.java:172) at org.apache.fop.fo.flow.Table.layout(Table.java:247) at org.apache.fop.fo.flow.Flow.layout(Flow.java:156) at org.apache.fop.fo.flow.Flow.layout(Flow.java:113) at org.apache.fop.fo.pagination.PageSequence.format(PageSequence.java:296) at org.apache.fop.apps.StreamRenderer.render(StreamRenderer.java:200) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:182) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.fop.apps.Driver.render(Driver.java:481) at org.apache.fop.apps.Driver.run(Driver.java:554) at com.db.eqr.ger.ui.web.company.pdf.GenerateMYPDF.createPDF(GenerateMYPDF.java:150) at com.db.eqr.ger.ui.web.company.pdf.CompanyPDFAction.execute(CompanyPDFAction.java:146) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:465) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1422) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:523) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1053) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387) at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:28) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27) Can anyone help me out and let me know what could be the problem here. I have used the following userconfig file. !--!DOCTYPE configuration SYSTEM config.dtd-- !-- this file contains templates which allow an user easy configuration of Fop. Actually normally you don't need this configuration file, but if you need to change configuration, you should always use this file and *not* config.xml. Usage: java org.apache.fop.apps.Fop -c userconfig.xml -fo fo-file -pdf pdf-file -- configuration !-- NOT IMPLEMENTED basedir: normally the base directory is the directory where the fo file is located. if you want to specify your own, uncomment this entry -- entry keybaseDir/key valuec:/shyamajoshi/conf/fop/value /entry !-- HYPHENATION
Re: Fonts and Document
On Mon, Mar 15, 2004 at 09:27:35AM +1000, Peter B. West wrote: Fops, What is the current situation with font information? I notice that the Document class now contains a lot of Font setup information, whilst a comprehensive set of font classes exists in ...fonts. I want to introduce font information into alt-design as compatibly as possible with HEAD. What do I need? I am completing my documentation on FOP code, see http://www.leverkruid.nl/FOP/index.html. I have a chapter on fonts. Maybe it helps you gain some quick insight. Regards, Simon Pepping -- Simon Pepping home page: http://www.leverkruid.nl
Re: Fonts and Document
On Mar 15, 2004, at 1:15 PM, Simon Pepping wrote: On Mon, Mar 15, 2004 at 09:27:35AM +1000, Peter B. West wrote: Fops, What is the current situation with font information? I notice that the Document class now contains a lot of Font setup information, whilst a comprehensive set of font classes exists in ...fonts. I want to introduce font information into alt-design as compatibly as possible with HEAD. What do I need? I am completing my documentation on FOP code, see http://www.leverkruid.nl/FOP/index.html. I have a chapter on fonts. Maybe it helps you gain some quick insight. Regards, Simon Pepping -- Simon Pepping home page: http://www.leverkruid.nl Looks good, Simon... I don't suppose you could create a PDF version? (I know a great XML = PDF conversion tool. :-)) Seriously though, this looks like a great potential addition to the Developer documentation we have on the FOP site. BTW, it looks like everything after Chapter 2, #3 is under PRE or CODE tags, so you've lost the formatting. Cheers! Web Maestro Clay
Re: Fonts and Document
The font subsystem is still far from finished. It's still quite complex to understand, unnecessarily so IMO. My font source idea still need to be implemented... Let's see if I can pull together some connectors. As you've seen the Document class is a central class in font handling. It currently (not in my ideas) provides direct access to font metric information and to the list of fonts actually used in a rendering run (we don't always want to embedd them all). The setup of all fonts is done in the FontSetup class where the base 14 fonts are defined. Additionally, custom fonts are added there. But the custom fonts are mostly renderer-dependant, so at the moment, some font setup also takes place in PDFRenderer for example. See PDFRenderer.configure (which can build custom font information using an Avalon Configuration object using a helper method from FontSetup) and PrintRenderer.setupFontInfo which actually triggers the font setup. The fonts get registered with the Document object and subsequently is available to the layout engine. Most font classes in the fonts package deal with the different font formats (single byte und unicode, base und custom...). There's also a difference in audience: The layout needs different information (metrics in particular) than the renderers (primarily information for using and embedding the font in the target format. Just a quick write-up, but I hope it still helps a bit. On 15.03.2004 00:27:35 Peter B. West wrote: Fops, What is the current situation with font information? I notice that the Document class now contains a lot of Font setup information, whilst a comprehensive set of font classes exists in ...fonts. I want to introduce font information into alt-design as compatibly as possible with HEAD. What do I need? Jeremias Maerki
cvs commit: xml-fop/src/java/org/apache/fop/fonts/type1 PFMFile.java
pbwest 2004/03/13 00:46:05
Modified:src/java/org/apache/fop/render Tag: FOP_0-20-0_Alt-Design
RendererContext.java AbstractRenderer.java
Renderer.java
src/java/org/apache/fop/render/awt Tag:
FOP_0-20-0_Alt-Design AWTRenderer.java
src/java/org/apache/fop/fonts/truetype Tag:
FOP_0-20-0_Alt-Design TTFFile.java
FontFileReader.java TTFSubSetFile.java
src/java/org/apache/fop/fonts/type1 Tag:
FOP_0-20-0_Alt-Design PFMFile.java
Log:
Tidied up to suppress Eclipse nagging
Revision ChangesPath
No revision
No revision
1.3.2.2 +1 -1 xml-fop/src/java/org/apache/fop/render/RendererContext.java
Index: RendererContext.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/render/RendererContext.java,v
retrieving revision 1.3.2.1
retrieving revision 1.3.2.2
diff -u -r1.3.2.1 -r1.3.2.2
--- RendererContext.java 10 Mar 2004 06:24:27 - 1.3.2.1
+++ RendererContext.java 13 Mar 2004 08:46:05 - 1.3.2.2
@@ -22,7 +22,7 @@
import java.util.Map;
//FOP
-import org.apache.fop.apps.FOUserAgent;
+import org.apache.fop.configuration.FOUserAgent;
/**
* The Render Context for external handlers. This provides a rendering context
1.24.2.2 +1 -1 xml-fop/src/java/org/apache/fop/render/AbstractRenderer.java
Index: AbstractRenderer.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/render/AbstractRenderer.java,v
retrieving revision 1.24.2.1
retrieving revision 1.24.2.2
diff -u -r1.24.2.1 -r1.24.2.2
--- AbstractRenderer.java 10 Mar 2004 06:24:27 - 1.24.2.1
+++ AbstractRenderer.java 13 Mar 2004 08:46:05 - 1.24.2.2
@@ -30,8 +30,8 @@
import org.apache.fop.area.CoordTransformer;
import org.apache.fop.area.PageViewport;
import org.apache.fop.area.RegionViewport;
-import org.apache.fop.apps.FOUserAgent;
import org.apache.fop.apps.Fop;
+import org.apache.fop.configuration.FOUserAgent;
import org.apache.avalon.framework.configuration.Configurable;
import org.apache.avalon.framework.configuration.Configuration;
1.8.2.2 +1 -1 xml-fop/src/java/org/apache/fop/render/Renderer.java
Index: Renderer.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/render/Renderer.java,v
retrieving revision 1.8.2.1
retrieving revision 1.8.2.2
diff -u -r1.8.2.1 -r1.8.2.2
--- Renderer.java 10 Mar 2004 06:24:27 - 1.8.2.1
+++ Renderer.java 13 Mar 2004 08:46:05 - 1.8.2.2
@@ -27,7 +27,7 @@
// FOP
import org.apache.fop.apps.FOPException;
import org.apache.fop.area.PageViewport;
-import org.apache.fop.apps.FOUserAgent;
+import org.apache.fop.configuration.FOUserAgent;
/**
* Interface implemented by all renderers. This interface is used to control
No revision
No revision
1.21.2.2 +0 -4 xml-fop/src/java/org/apache/fop/render/awt/AWTRenderer.java
Index: AWTRenderer.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/render/awt/AWTRenderer.java,v
retrieving revision 1.21.2.1
retrieving revision 1.21.2.2
diff -u -r1.21.2.1 -r1.21.2.2
--- AWTRenderer.java 10 Mar 2004 06:24:28 - 1.21.2.1
+++ AWTRenderer.java 13 Mar 2004 08:46:05 - 1.21.2.2
@@ -29,13 +29,9 @@
import java.awt.Color;
import java.awt.Dimension;
import java.awt.Graphics;
-import java.awt.Graphics2D;
-import java.awt.RenderingHints;
import java.awt.Toolkit;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
-import java.awt.geom.AffineTransform;
-import java.awt.geom.Rectangle2D;
import java.awt.image.BufferedImage;
import java.awt.print.PageFormat;
import java.awt.print.Pageable;
No revision
No revision
1.5.2.2 +18 -18xml-fop/src/java/org/apache/fop/fonts/truetype/TTFFile.java
Index: TTFFile.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/truetype/TTFFile.java,v
retrieving revision 1.5.2.1
retrieving revision 1.5.2.2
diff -u -r1.5.2.1 -r1.5.2.2
--- TTFFile.java 10 Mar 2004 06:24:28 - 1.5.2.1
+++ TTFFile.java 13 Mar 2004 08:46:05 - 1.5.2.2
@@ -380,7 +380,7 @@
ansiIndex = new java.util.HashMap();
for (int i = 32; i Glyphs.WINANSI_ENCODING.length; i++) {
Integer ansi
cvs commit: xml-fop/src/java/org/apache/fop/fonts MultiByteFont.java FontUtil.java Font.java
pbwest 2004/03/10 04:36:53
Modified:src/java/org/apache/fop/fonts Tag: FOP_0-20-0_Alt-Design
MultiByteFont.java FontUtil.java Font.java
Log:
Cosmetic changes to keep Eclipse happy
Revision ChangesPath
No revision
No revision
1.5.2.2 +1 -1 xml-fop/src/java/org/apache/fop/fonts/MultiByteFont.java
Index: MultiByteFont.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/MultiByteFont.java,v
retrieving revision 1.5.2.1
retrieving revision 1.5.2.2
diff -u -r1.5.2.1 -r1.5.2.2
--- MultiByteFont.java10 Mar 2004 06:24:28 - 1.5.2.1
+++ MultiByteFont.java10 Mar 2004 12:36:53 - 1.5.2.2
@@ -200,7 +200,7 @@
* @see org.apache.fop.fonts.Font#mapChar(char)
*/
public char mapChar(char c) {
-int idx = (int)c;
+int idx = c;
int retIdx = 0;
for (int i = 0; (i bfentries.length) retIdx == 0; i++) {
1.2.2.2 +2 -2 xml-fop/src/java/org/apache/fop/fonts/FontUtil.java
Index: FontUtil.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/FontUtil.java,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- FontUtil.java 10 Mar 2004 06:24:28 - 1.2.2.1
+++ FontUtil.java 10 Mar 2004 12:36:53 - 1.2.2.2
@@ -35,7 +35,7 @@
int weight = 400;
try {
weight = Integer.parseInt(text);
-weight = ((int)weight / 100) * 100;
+weight = (weight / 100) * 100;
weight = Math.max(weight, 100);
weight = Math.min(weight, 900);
} catch (NumberFormatException nfe) {
1.1.2.4 +0 -1 xml-fop/src/java/org/apache/fop/fonts/Font.java
Index: Font.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/Font.java,v
retrieving revision 1.1.2.3
retrieving revision 1.1.2.4
diff -u -r1.1.2.3 -r1.1.2.4
--- Font.java 10 Mar 2004 06:24:28 - 1.1.2.3
+++ Font.java 10 Mar 2004 12:36:53 - 1.1.2.4
@@ -182,7 +182,6 @@
* This also performs some guessing on widths on various
* versions of space that might not exists in the font.
* @param c character to inspect
- * @param fs FontState to use
* @return the width of the character
*/
public int getCharWidth(char c) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/fonts/apps PFMReader.java TTFReader.java
jeremias2004/02/27 09:46:06 Modified:src/java/org/apache/fop/fonts/apps PFMReader.java TTFReader.java Log: Applied Apache License Version 2.0 by following the instructions at http://www.apache.org/dev/apply-license.html. Revision ChangesPath 1.2 +16 -48xml-fop/src/java/org/apache/fop/fonts/apps/PFMReader.java Index: PFMReader.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/apps/PFMReader.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- PFMReader.java11 Mar 2003 13:05:39 - 1.1 +++ PFMReader.java27 Feb 2004 17:46:06 - 1.2 @@ -1,53 +1,21 @@ /* - * $Id$ - * - *The Apache Software License, Version 1.1 - * + * Copyright 1999-2004 The Apache Software Foundation. * - * Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved. - * - * Redistribution and use in source and binary forms, with or without modifica- - * tion, are permitted provided that the following conditions are met: - * - * 1. Redistributions of source code must retain the above copyright notice, - *this list of conditions and the following disclaimer. - * - * 2. Redistributions in binary form must reproduce the above copyright notice, - *this list of conditions and the following disclaimer in the documentation - *and/or other materials provided with the distribution. - * - * 3. The end-user documentation included with the redistribution, if any, must - *include the following acknowledgment: This product includes software - *developed by the Apache Software Foundation (http://www.apache.org/). - *Alternately, this acknowledgment may appear in the software itself, if - *and wherever such third-party acknowledgments normally appear. - * - * 4. The names FOP and Apache Software Foundation must not be used to - *endorse or promote products derived from this software without prior - *written permission. For written permission, please contact - *[EMAIL PROTECTED] - * - * 5. Products derived from this software may not be called Apache, nor may - *Apache appear in their name, without prior written permission of the - *Apache Software Foundation. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, - * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND - * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE - * APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, - * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU- - * DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON - * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * - * This software consists of voluntary contributions made by many individuals - * on behalf of the Apache Software Foundation and was originally created by - * James Tauber [EMAIL PROTECTED]. For more information on the Apache - * Software Foundation, please see http://www.apache.org/. - */ + * Licensed under the Apache License, Version 2.0 (the License); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an AS IS BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +/* $Id$ */ + package org.apache.fop.fonts.apps; import java.io.File; 1.3 +16 -48xml-fop/src/java/org/apache/fop/fonts/apps/TTFReader.java Index: TTFReader.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/apps/TTFReader.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- TTFReader.java27 May 2003 14:01:25 - 1.2 +++ TTFReader.java27 Feb 2004 17:46:06 - 1.3 @@ -1,53 +1,21 @@ /* - * $Id
cvs commit: xml-fop/src/java/org/apache/fop/fonts/truetype FontFileReader.java TTFCmapEntry.java TTFDirTabEntry.java TTFFile.java TTFMtxEntry.java TTFSubSetFile.java
jeremias2004/02/27 09:46:38 Modified:src/java/org/apache/fop/fonts/truetype FontFileReader.java TTFCmapEntry.java TTFDirTabEntry.java TTFFile.java TTFMtxEntry.java TTFSubSetFile.java Log: Applied Apache License Version 2.0 by following the instructions at http://www.apache.org/dev/apply-license.html. Revision ChangesPath 1.4 +16 -48 xml-fop/src/java/org/apache/fop/fonts/truetype/FontFileReader.java Index: FontFileReader.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/truetype/FontFileReader.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- FontFileReader.java 6 Feb 2004 21:49:28 - 1.3 +++ FontFileReader.java 27 Feb 2004 17:46:38 - 1.4 @@ -1,53 +1,21 @@ /* - * $Id$ - * - *The Apache Software License, Version 1.1 - * + * Copyright 1999-2004 The Apache Software Foundation. * - * Copyright (C) 1999-2004 The Apache Software Foundation. All rights reserved. - * - * Redistribution and use in source and binary forms, with or without modifica- - * tion, are permitted provided that the following conditions are met: - * - * 1. Redistributions of source code must retain the above copyright notice, - *this list of conditions and the following disclaimer. - * - * 2. Redistributions in binary form must reproduce the above copyright notice, - *this list of conditions and the following disclaimer in the documentation - *and/or other materials provided with the distribution. - * - * 3. The end-user documentation included with the redistribution, if any, must - *include the following acknowledgment: This product includes software - *developed by the Apache Software Foundation (http://www.apache.org/). - *Alternately, this acknowledgment may appear in the software itself, if - *and wherever such third-party acknowledgments normally appear. - * - * 4. The names FOP and Apache Software Foundation must not be used to - *endorse or promote products derived from this software without prior - *written permission. For written permission, please contact - *[EMAIL PROTECTED] - * - * 5. Products derived from this software may not be called Apache, nor may - *Apache appear in their name, without prior written permission of the - *Apache Software Foundation. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, - * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND - * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE - * APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, - * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU- - * DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON - * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * - * This software consists of voluntary contributions made by many individuals - * on behalf of the Apache Software Foundation and was originally created by - * James Tauber [EMAIL PROTECTED]. For more information on the Apache - * Software Foundation, please see http://www.apache.org/. - */ + * Licensed under the Apache License, Version 2.0 (the License); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an AS IS BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +/* $Id$ */ + package org.apache.fop.fonts.truetype; import java.io.InputStream; 1.2 +16 -48xml-fop/src/java/org/apache/fop/fonts/truetype/TTFCmapEntry.java Index: TTFCmapEntry.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/truetype/TTFCmapEntry.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- TTFCmapEntry.java 11 Mar
cvs commit: xml-fop/src/java/org/apache/fop/fonts/type1 PFBData.java PFBParser.java PFMFile.java PFMInputStream.java
jeremias2004/02/27 09:46:54 Modified:src/java/org/apache/fop/fonts/type1 PFBData.java PFBParser.java PFMFile.java PFMInputStream.java Log: Applied Apache License Version 2.0 by following the instructions at http://www.apache.org/dev/apply-license.html. Revision ChangesPath 1.2 +16 -48xml-fop/src/java/org/apache/fop/fonts/type1/PFBData.java Index: PFBData.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/type1/PFBData.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- PFBData.java 11 Mar 2003 13:05:36 - 1.1 +++ PFBData.java 27 Feb 2004 17:46:54 - 1.2 @@ -1,53 +1,21 @@ /* - * $Id$ - * - *The Apache Software License, Version 1.1 - * + * Copyright 1999-2004 The Apache Software Foundation. * - * Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved. - * - * Redistribution and use in source and binary forms, with or without modifica- - * tion, are permitted provided that the following conditions are met: - * - * 1. Redistributions of source code must retain the above copyright notice, - *this list of conditions and the following disclaimer. - * - * 2. Redistributions in binary form must reproduce the above copyright notice, - *this list of conditions and the following disclaimer in the documentation - *and/or other materials provided with the distribution. - * - * 3. The end-user documentation included with the redistribution, if any, must - *include the following acknowledgment: This product includes software - *developed by the Apache Software Foundation (http://www.apache.org/). - *Alternately, this acknowledgment may appear in the software itself, if - *and wherever such third-party acknowledgments normally appear. - * - * 4. The names FOP and Apache Software Foundation must not be used to - *endorse or promote products derived from this software without prior - *written permission. For written permission, please contact - *[EMAIL PROTECTED] - * - * 5. Products derived from this software may not be called Apache, nor may - *Apache appear in their name, without prior written permission of the - *Apache Software Foundation. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, - * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND - * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE - * APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, - * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU- - * DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON - * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * - * This software consists of voluntary contributions made by many individuals - * on behalf of the Apache Software Foundation and was originally created by - * James Tauber [EMAIL PROTECTED]. For more information on the Apache - * Software Foundation, please see http://www.apache.org/. - */ + * Licensed under the Apache License, Version 2.0 (the License); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an AS IS BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +/* $Id$ */ + package org.apache.fop.fonts.type1; import java.io.OutputStream; 1.4 +16 -48xml-fop/src/java/org/apache/fop/fonts/type1/PFBParser.java Index: PFBParser.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/type1/PFBParser.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- PFBParser.java6 Feb 2004 21:49:28 - 1.3 +++ PFBParser.java27 Feb 2004 17:46:54 - 1.4 @@ -1,53 +1,21 @@ /* - * $Id
cvs commit: xml-fop/src/java/org/apache/fop/fonts/truetype FontFileReader.java TTFDirTabEntry.java
jeremias2004/02/06 13:49:28
Modified:src/java/org/apache/fop/pdf TempFileStreamCache.java
PDFFactory.java
src/java/org/apache/fop/fonts/type1 PFMFile.java
PFBParser.java
src/java/org/apache/fop/render/rtf/rtflib/rtfdoc
RtfExternalGraphic.java
src/java/org/apache/fop/fonts/truetype FontFileReader.java
TTFDirTabEntry.java
Log:
Adapt to changes in Commons IO's APIs.
Revision ChangesPath
1.4 +3 -3 xml-fop/src/java/org/apache/fop/pdf/TempFileStreamCache.java
Index: TempFileStreamCache.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/pdf/TempFileStreamCache.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- TempFileStreamCache.java 4 Jul 2003 20:12:59 - 1.3
+++ TempFileStreamCache.java 6 Feb 2004 21:49:28 - 1.4
@@ -4,7 +4,7 @@
*The Apache Software License, Version 1.1
*
*
- * Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
+ * Copyright (C) 1999-2004 The Apache Software Foundation. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without modifica-
* tion, are permitted provided that the following conditions are met:
@@ -57,7 +57,7 @@
import java.io.File;
//Commons
-import org.apache.commons.io.IOUtil;
+import org.apache.commons.io.CopyUtils;
/**
* StreamCache implementation that uses temporary files rather than heap.
@@ -124,7 +124,7 @@
// don't need a buffer because streamCopy is buffered
InputStream input = new java.io.FileInputStream(tempFile);
-final long bytesCopied = IOUtil.copy(input, out);
+final long bytesCopied = CopyUtils.copy(input, out);
input.close();
return (int)bytesCopied;
}
1.7 +3 -3 xml-fop/src/java/org/apache/fop/pdf/PDFFactory.java
Index: PDFFactory.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/pdf/PDFFactory.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- PDFFactory.java 30 Aug 2003 18:52:35 - 1.6
+++ PDFFactory.java 6 Feb 2004 21:49:28 - 1.7
@@ -4,7 +4,7 @@
*The Apache Software License, Version 1.1
*
*
- * Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
+ * Copyright (C) 1999-2004 The Apache Software Foundation. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without modifica-
* tion, are permitted provided that the following conditions are met:
@@ -59,7 +59,7 @@
// Apache libs
import org.apache.avalon.framework.container.ContainerUtil;
-import org.apache.commons.io.IOUtil;
+import org.apache.commons.io.IOUtils;
// FOP
import org.apache.fop.fonts.CIDFont;
@@ -1180,7 +1180,7 @@
embeddedFont = new PDFT1Stream();
((PDFT1Stream)embeddedFont).setData(pfb);
} else {
-byte[] file = IOUtil.toByteArray(in);
+byte[] file = IOUtils.toByteArray(in);
embeddedFont = new PDFTTFStream(file.length);
((PDFTTFStream)embeddedFont).setData(file, file.length);
}
1.4 +3 -3 xml-fop/src/java/org/apache/fop/fonts/type1/PFMFile.java
Index: PFMFile.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/type1/PFMFile.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- PFMFile.java 19 Aug 2003 00:53:54 - 1.3
+++ PFMFile.java 6 Feb 2004 21:49:28 - 1.4
@@ -4,7 +4,7 @@
*The Apache Software License, Version 1.1
*
*
- * Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
+ * Copyright (C) 1999-2004 The Apache Software Foundation. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without modifica-
* tion, are permitted provided that the following conditions are met:
@@ -57,7 +57,7 @@
// Apache libs
import org.apache.avalon.framework.logger.AbstractLogEnabled;
-import org.apache.commons.io.IOUtil;
+import org.apache.commons.io.IOUtils;
// FOP
import
DO NOT REPLY [Bug 21303] - Embeded Fonts and signets disturbed by encryption
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=21303. 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=21303 Embeded Fonts and signets disturbed by encryption --- Additional Comments From [EMAIL PROTECTED] 2003-12-01 19:18 --- Can anyone please tell me as to when this will be fixed?? Thanks in advance. Beena
DO NOT REPLY [Bug 21303] - Embeded Fonts and signets disturbed by encryption
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=21303. 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=21303 Embeded Fonts and signets disturbed by encryption --- Additional Comments From [EMAIL PROTECTED] 2003-12-01 20:28 --- Not anytime soon, I'm afraid. Actually, the problem is fixed in our main development tree (aka redesign), though that won't help you much until the that code is ready for a release. And that will still take some time. As a workaround you can use a third-party tool to encrypt the PDFs.
RE: [VOTE] Move org.apache.fop.pdf.FontSetup to fonts package
Glen Mazza wrote: Speaking of which, any objection if I promote the org.apache.fop.pdf.FontSetup to the top-level Fonts package? It is currently being referenced by the AWT, MIF, PS, RTF, and XML renderers (basically all of them), indicating that it's probably better placed there. Here's my +1. +1. I think I had done that on my local machine as part of a bunch of font changes that need to be made. I think it actually needs to be merged with another class (I forget which one), but we can work on that later. Victor Mote
Re: [VOTE] Move org.apache.fop.pdf.FontSetup to fonts package
Speaking of which, any objection if I promote the org.apache.fop.pdf.FontSetup to the top-level Fonts package? It is currently being referenced by the AWT, MIF, PS, RTF, and XML renderers (basically all of them), indicating that it's probably better placed there. Here's my +1. +1 J.Pietschmann
Re: [VOTE] Move org.apache.fop.pdf.FontSetup to fonts package
+1 On 20.11.2003 00:01:23 Glen Mazza wrote: Speaking of which, any objection if I promote the org.apache.fop.pdf.FontSetup to the top-level Fonts package? It is currently being referenced by the AWT, MIF, PS, RTF, and XML renderers (basically all of them), indicating that it's probably better placed there. Here's my +1. Jeremias Maerki
[VOTE] Move org.apache.fop.pdf.FontSetup to fonts package
--- Victor Mote [EMAIL PROTECTED] wrote: I'm not sure what you are asking for here. IIRC, layout.FontState has basically been moved to fonts.Font. What has happened (I think) is that the font variant code was added to the maintenance branch, but not to the trunk. I actually don't have much insight at the moment on whether the applicable maintenance branch code can just be brought across to the trunk. Speaking of which, any objection if I promote the org.apache.fop.pdf.FontSetup to the top-level Fonts package? It is currently being referenced by the AWT, MIF, PS, RTF, and XML renderers (basically all of them), indicating that it's probably better placed there. Here's my +1. Thanks, Glen __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
Re: trunk config, fonts
Until recently, the command-line interface of the trunk was basically ignored due to other priorities. Configuration certainly has changed a bit, but is obviously unfinished (Gradual move to Avalon Configuration, inrtoduction of the Confihurable interface, work in progress). IMO it's low priority to fix the command-line in the trunk. Until we have some almost-0.20.5-level in layout, the CLI is not very helpful. On 29.07.2003 03:54:22 Victor Mote wrote: 2. In the trunk, the -x command-line option seems to be ignored. Also, AFAICT, the -c option appears to be ignored as well. At least custom font information seems to be ignored, with no message being logged to tell what is going on. (I tested identical setups with the maintenance branch, which works, and the trunk, which does not). Have our command-line options and/or our configuration file format changed? Or is something broken? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: trunk config, fonts
Jeremias Maerki wrote: Until recently, the command-line interface of the trunk was basically ignored due to other priorities. Configuration certainly has changed a bit, but is obviously unfinished (Gradual move to Avalon Configuration, inrtoduction of the Confihurable interface, work in progress). IMO it's low priority to fix the command-line in the trunk. Until we have some almost-0.20.5-level in layout, the CLI is not very helpful. It may not be too much of a loss, but I won't be able to test the trunk until either a CLI is implemented, or I learn to run Java applets... Web Maestro Clay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: trunk config, fonts
From: Clay Leeds [EMAIL PROTECTED] snip/ It may not be too much of a loss, but I won't be able to test the trunk until either a CLI is implemented, or I learn to run Java applets... It would be a loss. If you could spare time to test the trunk, you could report back on which bits of layout need attention. A sort of gap analysis for basic FO documents would be really useful. This in turn would help encourage development of the layout. I have run the trunk code before in an attempt to do this. I believe Victor and Jeremias were referring to the fact that you cant specify -c -d etc options on command line. You can still run FOP from command line, but FO to PDF only. Chris _ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: trunk config, fonts
Chris Bowditch wrote: It would be a loss. If you could spare time to test the trunk, you could report back on which bits of layout need attention. A sort of gap analysis for basic FO documents would be really useful. This in turn would help encourage development of the layout. I have run the trunk code before in an attempt to do this. I believe Victor and Jeremias were referring to the fact that you cant specify -c -d etc options on command line. You can still run FOP from command line, but FO to PDF only. Right. I have some changes related to custom fonts that I want to submit, and more I want to make, but it seemed unwise to commit them without being able to see the before and after results. In other words, we need at least some basic way of doing regression testing. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21982] New: - NullPointer Exception in LazyFont with embedded fonts (japanese fonts) in AIX
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=21982. 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=21982 NullPointer Exception in LazyFont with embedded fonts (japanese fonts) in AIX Summary: NullPointer Exception in LazyFont with embedded fonts (japanese fonts) in AIX Product: Fop Version: 0.20.4 Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] My fop.jar has a userconfig.xml that defines MSMincho for when I need to render Japanese text. This works fine on Windows systems, but throws a NullPointerException when fop.jar runs from AIX The exception is: java.lang.NullPointerException at org.apache.fop.render.pdf.fonts.LazyFont.getAscender(Unknown Source) at org.apache.fop.layout.FontState.getAscender(Unknown Source) at org.apache.fop.layout.LineArea.(Unknown Source) at org.apache.fop.layout.BlockArea.start(Unknown Source) at org.apache.fop.fo.flow.Block.layout(Unknown Source) at org.apache.fop.fo.flow.TableCell.layout(Unknown Source) at org.apache.fop.fo.flow.TableRow.layout(Unknown Source) at org.apache.fop.fo.flow.TableBody.layout(Unknown Source) at org.apache.fop.fo.flow.Table.layout(Unknown Source) at org.apache.fop.fo.flow.Block.layout(Unknown Source) at org.apache.fop.fo.flow.StaticContent.layout(Unknown Source) at org.apache.fop.fo.pagination.PageSequence.layoutStaticContent (Unknown Source) at org.apache.fop.fo.pagination.PageSequence.formatStaticContent (Unknown Source) at org.apache.fop.fo.pagination.PageSequence.format(Unknown Source) at org.apache.fop.apps.StreamRenderer.render(Unknown Source) at org.apache.fop.fo.FOTreeBuilder.endElement(Unknown Source) at weblogic.apache.xerces.parsers.SAXParser.endElement(SAXParser.java (Compiled Code)) at weblogic.apache.xerces.validators.common.XMLValidator.callEndElement (XMLValidator.java(Compiled Code)) at weblogic.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch (XMLDocumentScanner.java(Compiled Code)) at weblogic.apache.xerces.framework.XMLDocumentScanner.parseSome (XMLDocumentScanner.java(Compiled Code)) at weblogic.apache.xerces.framework.XMLParser.parse(XMLParser.java:1119) at weblogic.xml.jaxp.WebLogicXMLReader.parse(WebLogicXMLReader.java:135) at weblogic.xml.jaxp.RegistryXMLReader.parse(RegistryXMLReader.java:133) at org.apache.fop.apps.Driver.render(Unknown Source) at com.alphablox.xsl.PdfTransformer.runTask(Unknown Source) at com.alphablox.util.threadpool.WorkerThread.run(Unknown Source) This is also failing with 0.20.5 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21982] - NullPointer Exception in LazyFont with embedded fonts (japanese fonts) in AIX
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=21982. 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=21982 NullPointer Exception in LazyFont with embedded fonts (japanese fonts) in AIX [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Other |AIX Platform|Other |All - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
trunk config, fonts
Hi crew: 1. In the maintenance branch, the -x command-line option appears to *only* spit out the configuration information, then bail out. Is that the desired behavior? If so, I should probably update the doc to reflect that. 2. In the trunk, the -x command-line option seems to be ignored. Also, AFAICT, the -c option appears to be ignored as well. At least custom font information seems to be ignored, with no message being logged to tell what is going on. (I tested identical setups with the maintenance branch, which works, and the trunk, which does not). Have our command-line options and/or our configuration file format changed? Or is something broken? Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/codegen/org/apache/fop/fonts CodePointMapping.java
pbwest 2003/07/08 04:26:58 Modified:src/codegen/org/apache/fop/fonts Tag: FOP_0-20-0_Alt-Design CodePointMapping.java Log: Generated with modified code-point-mapping.xsl to include licence. Revision ChangesPath No revision No revision 1.1.2.2 +55 -0 xml-fop/src/codegen/org/apache/fop/fonts/Attic/CodePointMapping.java Index: CodePointMapping.java === RCS file: /home/cvs/xml-fop/src/codegen/org/apache/fop/fonts/Attic/CodePointMapping.java,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- CodePointMapping.java 5 Jul 2003 19:29:10 - 1.1.2.1 +++ CodePointMapping.java 8 Jul 2003 11:26:58 - 1.1.2.2 @@ -1,3 +1,58 @@ +/* + $Id$ + * + *The Apache Software License, Version 1.1 + * + * + * Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without modifica- + * tion, are permitted provided that the following conditions are met: + * + * 1. Redistributions of source code must retain the above copyright notice, + *this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright notice, + *this list of conditions and the following disclaimer in the documentation + *and/or other materials provided with the distribution. + * + * 3. The end-user documentation included with the redistribution, if any, must + *include the following acknowledgment: This product includes software + *developed by the Apache Software Foundation (http://www.apache.org/). + *Alternately, this acknowledgment may appear in the software itself, if + *and wherever such third-party acknowledgments normally appear. + * + * 4. The names FOP and Apache Software Foundation must not be used to + *endorse or promote products derived from this software without prior + *written permission. For written permission, please contact + *[EMAIL PROTECTED] + * + * 5. Products derived from this software may not be called Apache, nor may + *Apache appear in their name, without prior written permission of the + *Apache Software Foundation. + * + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, + * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND + * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE + * APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, + * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU- + * DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS + * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * + * This software consists of voluntary contributions made by many individuals + * on behalf of the Apache Software Foundation and was originally created by + * James Tauber [EMAIL PROTECTED]. For more information on the Apache + * Software Foundation, please see http://www.apache.org/. + * + *!!! + * Automatically generated from encodings.xml and glyphlist.xml ! + * by code-point-mapping.xsl. DO NOT EDIT! + *!!! + */ package org.apache.fop.fonts; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/codegen/org/apache/fop/fonts/base14 CourierBold.java Symbol.java Courier.java CourierOblique.java Helvetica.java HelveticaBoldOblique.java CourierBoldOblique.java TimesBoldItalic.java ZapfDingbats.java TimesBold.java TimesItalic.java HelveticaBold.java HelveticaOblique.java TimesRoman.java
pbwest 2003/07/08 04:52:24 Modified:src/codegen/org/apache/fop/fonts/base14 Tag: FOP_0-20-0_Alt-Design CourierBold.java Symbol.java Courier.java CourierOblique.java Helvetica.java HelveticaBoldOblique.java CourierBoldOblique.java TimesBoldItalic.java ZapfDingbats.java TimesBold.java TimesItalic.java HelveticaBold.java HelveticaOblique.java TimesRoman.java Log: Change as a result of modifcation to generating script. Revision ChangesPath No revision No revision 1.1.2.2 +2 -2 xml-fop/src/codegen/org/apache/fop/fonts/base14/Attic/CourierBold.java Index: CourierBold.java === RCS file: /home/cvs/xml-fop/src/codegen/org/apache/fop/fonts/base14/Attic/CourierBold.java,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- CourierBold.java 5 Jul 2003 19:29:09 - 1.1.2.1 +++ CourierBold.java 8 Jul 2003 11:52:23 - 1.1.2.2 @@ -52,7 +52,7 @@ * Automatically generated by font-file.xsl. DO NOT EDIT! * */ - + package org.apache.fop.fonts.base14; import org.apache.fop.fonts.FontType; 1.1.2.2 +2 -2 xml-fop/src/codegen/org/apache/fop/fonts/base14/Attic/Symbol.java Index: Symbol.java === RCS file: /home/cvs/xml-fop/src/codegen/org/apache/fop/fonts/base14/Attic/Symbol.java,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- Symbol.java 5 Jul 2003 19:29:09 - 1.1.2.1 +++ Symbol.java 8 Jul 2003 11:52:23 - 1.1.2.2 @@ -52,7 +52,7 @@ * Automatically generated by font-file.xsl. DO NOT EDIT! * */ - + package org.apache.fop.fonts.base14; import org.apache.fop.fonts.FontType; 1.1.2.2 +2 -2 xml-fop/src/codegen/org/apache/fop/fonts/base14/Attic/Courier.java Index: Courier.java === RCS file: /home/cvs/xml-fop/src/codegen/org/apache/fop/fonts/base14/Attic/Courier.java,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- Courier.java 5 Jul 2003 19:29:09 - 1.1.2.1 +++ Courier.java 8 Jul 2003 11:52:23 - 1.1.2.2 @@ -52,7 +52,7 @@ * Automatically generated by font-file.xsl. DO NOT EDIT! * */ - + package org.apache.fop.fonts.base14; import org.apache.fop.fonts.FontType; 1.1.2.2 +2 -2 xml-fop/src/codegen/org/apache/fop/fonts/base14/Attic/CourierOblique.java Index: CourierOblique.java === RCS file: /home/cvs/xml-fop/src/codegen/org/apache/fop/fonts/base14/Attic/CourierOblique.java,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- CourierOblique.java 5 Jul 2003 19:29:09 - 1.1.2.1 +++ CourierOblique.java 8 Jul 2003 11:52:23 - 1.1.2.2 @@ -52,7 +52,7 @@ * Automatically generated by font-file.xsl. DO NOT EDIT! * */ - + package org.apache.fop.fonts.base14; import org.apache.fop.fonts.FontType; 1.1.2.2 +2 -2 xml-fop/src/codegen/org/apache/fop/fonts/base14/Attic/Helvetica.java Index: Helvetica.java === RCS file: /home/cvs/xml-fop/src/codegen/org/apache/fop/fonts/base14/Attic/Helvetica.java,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- Helvetica.java5 Jul 2003 19:29:09 - 1.1.2.1 +++ Helvetica.java8 Jul 2003 11:52:23 - 1.1.2.2 @@ -52,7 +52,7 @@ * Automatically generated by font-file.xsl. DO NOT EDIT! * */ - + package org.apache.fop.fonts.base14; import org.apache.fop.fonts.FontType; 1.1.2.2 +2 -2 xml-fop/src/codegen/org/apache/fop/fonts/base14/Attic/HelveticaBoldOblique.java Index: HelveticaBoldOblique.java === RCS file: /home/cvs/xml-fop/src/codegen/org/apache/fop/fonts/base14/Attic/HelveticaBoldOblique.java,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- HelveticaBoldOblique.java 5 Jul 2003 19:29:09 - 1.1.2.1
awtRenderer and fonts
Hi: I'm a long-time FOP User and code tweaker, and have been trying to get the AWTRenderer to do its thing for a part of a project I'm working on. For the most part, I've been successful here, but for the life of me, I can't get the fonts to render properly. Everything seems to want to render to either times or lucida sans. Similar runs out to pdf generate the fonts just fine. I've been checking out font.properties, Oleg's TiffRenderer, etc, but can't seem to find any good fix. Does anyone have any ideas? I'd really appreciate it. jw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/fonts FontMetrics.java Font.java FontDescriptor.java FontType.java Glyphs.java package.html
pbwest 2003/07/05 12:09:29 Added: src/java/org/apache/fop/fonts Tag: FOP_0-20-0_Alt-Design FontMetrics.java Font.java FontDescriptor.java FontType.java Glyphs.java package.html Log: Moved from src to src/java. Revision ChangesPath No revision No revision 1.1.2.1 +0 -0 xml-fop/src/java/org/apache/fop/fonts/FontMetrics.java Index: FontMetrics.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/FontMetrics.java,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 1.1.2.1 +0 -0 xml-fop/src/java/org/apache/fop/fonts/Font.java Index: Font.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/Font.java,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 1.1.2.1 +0 -0 xml-fop/src/java/org/apache/fop/fonts/FontDescriptor.java Index: FontDescriptor.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/FontDescriptor.java,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 1.1.2.1 +0 -0 xml-fop/src/java/org/apache/fop/fonts/FontType.java Index: FontType.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/FontType.java,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 1.3.2.1 +0 -0 xml-fop/src/java/org/apache/fop/fonts/Glyphs.java Index: Glyphs.java === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/Glyphs.java,v retrieving revision 1.3 retrieving revision 1.3.2.1 diff -u -r1.3 -r1.3.2.1 1.1.2.1 +0 -0 xml-fop/src/java/org/apache/fop/fonts/package.html Index: package.html === RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/package.html,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/codegen/org/apache/fop/fonts - New directory
pbwest 2003/07/05 12:28:34 xml-fop/src/codegen/org/apache/fop/fonts - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/codegen/org/apache/fop/fonts/base14 - New directory
pbwest 2003/07/05 12:28:34 xml-fop/src/codegen/org/apache/fop/fonts/base14 - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21303] New: - Embeded Fonts and signets disturbed by encryption
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=21303. 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=21303 Embeded Fonts and signets disturbed by encryption Summary: Embeded Fonts and signets disturbed by encryption Product: Fop Version: 0.20.5 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am using FOP 0.20.5RC3a with JDK1.4.0 and bcprov-jdk14-119.jar for Encryption. I have FO doc including Batang font and Signets (fox:outline tags). Works well without protections. But with '-o' or '-noread', Signets are coded (not readable), and Font is not retreived. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: xml-fop/src/org/apache/fop/fonts Glyphs.java
Jeremias, Shouldn't we acknowledge this support on the web site? Peter [EMAIL PROTECTED] wrote: Log: Fix bug in WinAnsiEncoding: trademark was shown as bullet Financed by: CTB/McGraw-Hill -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: xml-fop/src/org/apache/fop/fonts Glyphs.java
There are pros and cons: + Might encourage other companies also to support FOP. + Gives credit where credit is due. - As with the contributor's list, if we start the list now, we don't acknowledge former contributions. And completing such a list is some tedious work. Just missing former contributors/supporters out is unfair IMO. And if we start a list of companies/organizations supporting FOP we would also need to acknowledge the employers of committers/developers if they grant their employees time to work on FOP. I'd like to hear other opinions. On 04.06.2003 01:15:03 Peter B. West wrote: Shouldn't we acknowledge this support on the web site? [EMAIL PROTECTED] wrote: Log: Fix bug in WinAnsiEncoding: trademark was shown as bullet Financed by: CTB/McGraw-Hill Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: xml-fop/src/org/apache/fop/fonts Glyphs.java
I'm surprised that we haven't always acknowledged contributions, at the option of the contributor. I suppose there are a number of questions that arise, and I wonder if the ASF has considered this question. For example, the Xerces and Xalan development is heavy with IBM personnel, yet I see no acknowledgement of IBM's ongoing involvement. Peter Jeremias Maerki wrote: There are pros and cons: + Might encourage other companies also to support FOP. + Gives credit where credit is due. - As with the contributor's list, if we start the list now, we don't acknowledge former contributions. And completing such a list is some tedious work. Just missing former contributors/supporters out is unfair IMO. And if we start a list of companies/organizations supporting FOP we would also need to acknowledge the employers of committers/developers if they grant their employees time to work on FOP. I'd like to hear other opinions. On 04.06.2003 01:15:03 Peter B. West wrote: Shouldn't we acknowledge this support on the web site? [EMAIL PROTECTED] wrote: Log: Fix bug in WinAnsiEncoding: trademark was shown as bullet Financed by: CTB/McGraw-Hill -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fonts Glyphs.java
jeremias2003/06/02 12:52:51
Modified:src/org/apache/fop/fonts Tag: fop-0_20_2-maintain
Glyphs.java
Log:
Fix bug in WinAnsiEncoding: trademark was shown as bullet
Financed by: CTB/McGraw-Hill
Revision ChangesPath
No revision
No revision
1.7.2.3 +33 -22xml-fop/src/org/apache/fop/fonts/Attic/Glyphs.java
Index: Glyphs.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fonts/Attic/Glyphs.java,v
retrieving revision 1.7.2.2
retrieving revision 1.7.2.3
diff -u -r1.7.2.2 -r1.7.2.3
--- Glyphs.java 25 Feb 2003 13:13:21 - 1.7.2.2
+++ Glyphs.java 2 Jun 2003 19:52:50 - 1.7.2.3
@@ -3,34 +3,34 @@
*
*The Apache Software License, Version 1.1
*
- *
+ *
* Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
- *
+ *
* Redistribution and use in source and binary forms, with or without modifica-
* tion, are permitted provided that the following conditions are met:
- *
+ *
* 1. Redistributions of source code must retain the above copyright notice,
*this list of conditions and the following disclaimer.
- *
+ *
* 2. Redistributions in binary form must reproduce the above copyright notice,
*this list of conditions and the following disclaimer in the documentation
*and/or other materials provided with the distribution.
- *
+ *
* 3. The end-user documentation included with the redistribution, if any, must
*include the following acknowledgment: This product includes software
*developed by the Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgment may appear in the software itself, if
*and wherever such third-party acknowledgments normally appear.
- *
+ *
* 4. The names FOP and Apache Software Foundation must not be used to
*endorse or promote products derived from this software without prior
*written permission. For written permission, please contact
*[EMAIL PROTECTED]
- *
+ *
* 5. Products derived from this software may not be called Apache, nor may
*Apache appear in their name, without prior written permission of the
*Apache Software Foundation.
- *
+ *
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
* FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
@@ -42,12 +42,12 @@
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
- *
+ *
* This software consists of voluntary contributions made by many individuals
* on behalf of the Apache Software Foundation and was originally created by
* James Tauber [EMAIL PROTECTED]. For more information on the Apache
* Software Foundation, please see http://www.apache.org/.
- */
+ */
package org.apache.fop.fonts;
public class Glyphs {
@@ -195,30 +195,30 @@
'\u2022', // bullet
'\u2013', // endash
'\u2014', // emdash
-'~', '\u2022', // bullet
+'~', '\u2122', // trademark
'\u0161', '\u203a', '\u0153', '\u2022', '\u017e', '\u0178', // 0xA0
- ' ', '\u00a1', '\u00a2', '\u00a3', '\u00a4', '\u00a5',
- '\u00a6', '\u00a7', '\u00a8', '\u00a9', '\u00aa', '\u00ab',
+ ' ', '\u00a1', '\u00a2', '\u00a3', '\u00a4', '\u00a5',
+ '\u00a6', '\u00a7', '\u00a8', '\u00a9', '\u00aa', '\u00ab',
'\u00ac', '\u00ad', '\u00ae', '\u00af', // 0xb0
'\u00b0', '\u00b1', '\u00b2', '\u00b3', '\u00b4',
'\u00b5', // This is hand-coded, the
rest is assumption
'\u00b6', // and *might* not be
correct...
-'\u00b7', '\u00b8', '\u00b9', '\u00ba', '\u00bb', '\u00bc', '\u00bd',
+'\u00b7', '\u00b8', '\u00b9', '\u00ba', '\u00bb', '\u00bc', '\u00bd',
'\u00be', '\u00bf', // 0xc0
'\u00c0', '\u00c1', '\u00c2', '\u00c3', '\u00c4', '\u00c5', // Aring
'\u00c6',// AE
-'\u00c7', '\u00c8', '\u00c9', '\u00ca', '\u00cb', '\u00cc
cvs commit: xml-fop/src/java/org/apache/fop/fonts/type1 PFMFile.java
jeremias2003/06/02 12:58:55
Modified:src/java/org/apache/fop/fonts/type1 PFMFile.java
Log:
Use Commons IO methods
Revision ChangesPath
1.2 +5 -4 xml-fop/src/java/org/apache/fop/fonts/type1/PFMFile.java
Index: PFMFile.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/type1/PFMFile.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- PFMFile.java 11 Mar 2003 13:05:36 - 1.1
+++ PFMFile.java 2 Jun 2003 19:58:55 - 1.2
@@ -50,16 +50,17 @@
*/
package org.apache.fop.fonts.type1;
+// Java
import java.io.IOException;
import java.io.InputStream;
import java.util.Map;
-//Avalon
+// Apache libs
import org.apache.avalon.framework.logger.AbstractLogEnabled;
+import org.apache.commons.io.IOUtil;
-//FOP
+// FOP
import org.apache.fop.fonts.Glyphs;
-import org.apache.fop.util.StreamUtilities;
/**
* This class represents a PFM file (or parts of it) as a Java object.
@@ -100,7 +101,7 @@
* @throws IOException In case of an I/O problem
*/
public void load(InputStream inStream) throws IOException {
-final byte[] buf = StreamUtilities.toByteArray(inStream, 8000);
+final byte[] buf = IOUtil.toByteArray(inStream);
final InputStream bufin = new java.io.ByteArrayInputStream(buf);
PFMInputStream in = new PFMInputStream(bufin);
/*final int version =*/ in.readShort();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/fonts FontUtil.java
jeremias2003/06/02 12:59:43
Added: src/java/org/apache/fop/fonts FontUtil.java
Log:
Class with utility methods for fonts.
Revision ChangesPath
1.1 xml-fop/src/java/org/apache/fop/fonts/FontUtil.java
Index: FontUtil.java
===
/*
* $Id: FontUtil.java,v 1.1 2003/06/02 19:59:42 jeremias Exp $
*
*The Apache Software License, Version 1.1
*
*
* Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without modifica-
* tion, are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice,
*this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright notice,
*this list of conditions and the following disclaimer in the documentation
*and/or other materials provided with the distribution.
*
* 3. The end-user documentation included with the redistribution, if any, must
*include the following acknowledgment: This product includes software
*developed by the Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgment may appear in the software itself, if
*and wherever such third-party acknowledgments normally appear.
*
* 4. The names FOP and Apache Software Foundation must not be used to
*endorse or promote products derived from this software without prior
*written permission. For written permission, please contact
*[EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache, nor may
*Apache appear in their name, without prior written permission of the
*Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
* FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
* APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
* INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU-
* DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
* OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
* ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many individuals
* on behalf of the Apache Software Foundation and was originally created by
* James Tauber [EMAIL PROTECTED]. For more information on the Apache
* Software Foundation, please see http://www.apache.org/.
*/
package org.apache.fop.fonts;
/**
* Font utilities.
*/
public class FontUtil {
/**
* Parses an CSS2 (SVG and XSL-FO) font weight (normal, bold, 100-900) to
* an integer.
* See http://www.w3.org/TR/REC-CSS2/fonts.html#propdef-font-weight
* TODO: Implement lighter and bolder.
* @param text the font weight to parse
* @return an integer between 100 and 900 (100, 200, 300...)
*/
public static int parseCSS2FontWeight(String text) {
int weight = 400;
try {
weight = Integer.parseInt(text);
weight = ((int)weight / 100) * 100;
weight = Math.max(weight, 100);
weight = Math.min(weight, 900);
} catch (NumberFormatException nfe) {
//weight is no number, so convert symbolic name to number
if (text.equals(normal)) {
weight = 400;
} else if (text.equals(bold)) {
weight = 700;
} else {
throw new IllegalArgumentException(
Illegal value for font weight: '
+ text
+ '. Use one of: 100, 200, 300,
+ 400, 500, 600, 700, 800, 900,
+ normal (=400), bold (=700));
}
}
return weight;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/fonts Glyphs.java
jeremias2003/06/02 13:00:29
Modified:src/java/org/apache/fop/fonts Glyphs.java
Log:
Fix bug in WinAnsiEncoding: trademark was shown as bullet
Financed by: CTB/McGraw-Hill
Revision ChangesPath
1.2 +15 -1 xml-fop/src/java/org/apache/fop/fonts/Glyphs.java
Index: Glyphs.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/Glyphs.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Glyphs.java 11 Mar 2003 13:05:15 - 1.1
+++ Glyphs.java 2 Jun 2003 20:00:26 - 1.2
@@ -209,7 +209,8 @@
'\u2022', // bullet
'\u2013', // endash
'\u2014', // emdash
-'~', '\u2022', // bullet
+'~',
+'\u2122', // trademark
'\u0161', '\u203a', '\u0153', '\u2022', '\u017e', '\u0178', // 0xA0
' ', '\u00a1', '\u00a2', '\u00a3', '\u00a4', '\u00a5',
'\u00a6', '\u00a7', '\u00a8', '\u00a9', '\u00aa', '\u00ab',
@@ -1296,11 +1297,24 @@
};
/**
+ * Return the glyphname from a character,
+ * eg, charToGlyphName('\\') returns backslash
+ *
+ * @param ch glyph to evaluate
+ * @return the name of the glyph
+ */
+public static final String charToGlyphName(char ch) {
+return stringToGlyph(Character.toString(ch));
+}
+
+/**
* Return the glyphname from a string,
* eg, glyphToString(\\) returns backslash
*
* @param name glyph to evaluate
* @return the name of the glyph
+ * TODO: javadocs for glyphToString and stringToGlyph are confused
+ * TODO: Improve method names
*/
public static final String glyphToString(String name) {
for (int i = 0; i UNICODE_GLYPHS.length; i += 2) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fonts Glyphs.java
jeremias2003/06/02 14:38:39
Modified:src/org/apache/fop/fonts Tag: fop-0_20_2-maintain
Glyphs.java
Log:
Reestablish JDK 1.3 compatibility. Sorry!
Revision ChangesPath
No revision
No revision
1.7.2.4 +2 -2 xml-fop/src/org/apache/fop/fonts/Attic/Glyphs.java
Index: Glyphs.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fonts/Attic/Glyphs.java,v
retrieving revision 1.7.2.3
retrieving revision 1.7.2.4
diff -u -r1.7.2.3 -r1.7.2.4
--- Glyphs.java 2 Jun 2003 19:52:50 - 1.7.2.3
+++ Glyphs.java 2 Jun 2003 21:38:38 - 1.7.2.4
@@ -1287,7 +1287,7 @@
* @return the name of the glyph
*/
public static final String charToGlyphName(char ch) {
-return stringToGlyph(Character.toString(ch));
+return stringToGlyph(new Character(ch).toString());
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/fonts Glyphs.java
jeremias2003/06/02 14:40:02
Modified:src/java/org/apache/fop/fonts Glyphs.java
Log:
Reestablish JDK 1.3 compatibility. Sorry!
Revision ChangesPath
1.3 +1 -1 xml-fop/src/java/org/apache/fop/fonts/Glyphs.java
Index: Glyphs.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/Glyphs.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Glyphs.java 2 Jun 2003 20:00:26 - 1.2
+++ Glyphs.java 2 Jun 2003 21:40:02 - 1.3
@@ -1304,7 +1304,7 @@
* @return the name of the glyph
*/
public static final String charToGlyphName(char ch) {
-return stringToGlyph(Character.toString(ch));
+return stringToGlyph(new Character(ch).toString());
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/fonts MultiByteFont.java CIDFont.java
jeremias2003/04/03 04:53:44
Modified:src/java/org/apache/fop/render/pdf FontReader.java
src/java/org/apache/fop/pdf PDFFactory.java
src/java/org/apache/fop/fonts MultiByteFont.java
CIDFont.java
Log:
Fix TrueType embedding. Width array did not reflect the subset. Was my bad.
Revision ChangesPath
1.3 +1 -1 xml-fop/src/java/org/apache/fop/render/pdf/FontReader.java
Index: FontReader.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/render/pdf/FontReader.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- FontReader.java 15 Mar 2003 16:58:59 - 1.2
+++ FontReader.java 3 Apr 2003 12:53:44 - 1.3
@@ -304,7 +304,7 @@
wds[j++] = i.intValue();
}
-multiFont.addCIDWidthEntry(cidWidthIndex, wds);
+//multiFont.addCIDWidthEntry(cidWidthIndex, wds);
multiFont.setWidthArray(wds);
} else if (bfranges.equals(localName)) {
1.3 +1 -1 xml-fop/src/java/org/apache/fop/pdf/PDFFactory.java
Index: PDFFactory.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/pdf/PDFFactory.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- PDFFactory.java 27 Mar 2003 11:04:31 - 1.2
+++ PDFFactory.java 3 Apr 2003 12:53:44 - 1.3
@@ -1023,7 +1023,7 @@
new PDFCIDFont(basefont,
cidMetrics.getCIDType(),
cidMetrics.getDefaultWidth(),
- cidMetrics.getWidths(), sysInfo,
+ cidMetrics.getSubsetWidths(), sysInfo,
(PDFCIDFontDescriptor)pdfdesc);
getDocument().registerObject(cidFont);
1.2 +20 -19xml-fop/src/java/org/apache/fop/fonts/MultiByteFont.java
Index: MultiByteFont.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/MultiByteFont.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MultiByteFont.java11 Mar 2003 13:05:15 - 1.1
+++ MultiByteFont.java3 Apr 2003 12:53:44 - 1.2
@@ -73,7 +73,7 @@
private CIDFontType cidType = CIDFontType.CIDTYPE2;
private String namePrefix = null;// Quasi unique prefix
-private PDFWArray warray = new PDFWArray();
+//private PDFWArray warray = new PDFWArray();
private int width[] = null;
private BFEntry[] bfentries = null;
@@ -170,23 +170,6 @@
}
}
-/* unused
-public PDFWArray getWidthsAsPDFWArray() {
-if (isEmbeddable()) {
-// Create widths for reencoded chars
-warray = new PDFWArray();
-int[] tmpWidth = new int[usedGlyphsCount];
-
-for (int i = 0; i usedGlyphsCount; i++) {
-Integer nw = (Integer)usedGlyphsIndex.get(new Integer(i));
-int nwx = (nw == null) ? 0 : nw.intValue();
-tmpWidth[i] = width[nwx];
-}
-warray.addEntry(0, tmpWidth);
-}
-return warray;
-}*/
-
/**
* @see org.apache.fop.fonts.FontDescriptor#isEmbeddable()
*/
@@ -243,6 +226,23 @@
}
/**
+ * @see org.apache.fop.fonts.CIDFont#getSubsetWidths()
+ */
+public PDFWArray getSubsetWidths() {
+// Create widths for reencoded chars
+PDFWArray warray = new PDFWArray();
+int[] tmpWidth = new int[usedGlyphsCount];
+
+for (int i = 0; i usedGlyphsCount; i++) {
+Integer nw = (Integer)usedGlyphsIndex.get(new Integer(i));
+int nwx = (nw == null) ? 0 : nw.intValue();
+tmpWidth[i] = width[nwx];
+}
+warray.addEntry(0, tmpWidth);
+return warray;
+}
+
+/**
* Remaps a codepoint based.
* @param i codepoint to remap
* @return new codepoint
@@ -334,9 +334,10 @@
* @param cidWidthIndex index
* @param wds array of widths
*/
+/*
public void addCIDWidthEntry(int cidWidthIndex, int[] wds) {
this.warray.addEntry(cidWidthIndex, wds);
-}
+}*/
/**
1.2 +11 -1 xml-fop/src/java/org/apache/fop/fonts/CIDFont.java
Index: CIDFont.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/CIDFont.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u
cvs commit: xml-fop/src/java/org/apache/fop/fonts/truetype TTFFile.java
jeremias2003/03/27 02:06:16
Modified:src/java/org/apache/fop/fonts/truetype TTFFile.java
Log:
Reduce debug output. A constant can be modified to enable more extensive log output.
Revision ChangesPath
1.2 +11 -4 xml-fop/src/java/org/apache/fop/fonts/truetype/TTFFile.java
Index: TTFFile.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/truetype/TTFFile.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TTFFile.java 11 Mar 2003 13:05:23 - 1.1
+++ TTFFile.java 27 Mar 2003 10:06:16 - 1.2
@@ -72,6 +72,9 @@
static final int MAX_CHAR_CODE = 255;
static final int ENC_BUF_SIZE = 1024;
+/** Set to true to get even more debug output than with level DEBUG */
+public static final boolean TRACE_ENABLED = false;
+
private String encoding = WinAnsiEncoding;// Default encoding
private short firstChar = 0;
@@ -783,7 +786,9 @@
int mtxSize = Math.max(numberOfGlyphs, nhmtx);
mtxTab = new TTFMtxEntry[mtxSize];
-getLogger().debug(*** Widths array: \n);
+if (TRACE_ENABLED) {
+getLogger().debug(*** Widths array: \n);
+}
for (int i = 0; i mtxSize; i++) {
mtxTab[i] = new TTFMtxEntry();
}
@@ -791,9 +796,11 @@
mtxTab[i].setWx(in.readTTFUShort());
mtxTab[i].setLsb(in.readTTFUShort());
-if (getLogger().isDebugEnabled()) {
-getLogger().debug( width[ + i + ] =
-+ convertTTFUnit2PDFUnit(mtxTab[i].getWx()) + ;);
+if (TRACE_ENABLED) {
+if (getLogger().isDebugEnabled()) {
+getLogger().debug( width[ + i + ] =
++ convertTTFUnit2PDFUnit(mtxTab[i].getWx()) + ;);
+}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
SV: Embedding fonts!
I changed the class org.apache.fop.render.pdf.fonts.MultiByteFont.java. The namePrefix is always set to NULL. /Uwe -Ursprungligt meddelande- Från: Müller, Markus [mailto:[EMAIL PROTECTED] Skickat: den 17 mars 2003 15:36 Till: [EMAIL PROTECTED] Kopia: Klosa Uwe Ämne: AW: Embedding fonts! I'm not sure, but I remember we had a similar problem: Our corporate fonts were replaced by Acrobat with built-in fonts, since the font names in the PDF had a prefix like yours. So Acrobat could not find a font like 023442-Corporate12Bold. Try creating the font metrics file using that option. MM $ -Ursprüngliche Nachricht- $ Von: Uwe Klosa [mailto:[EMAIL PROTECTED] $ Gesendet: Montag, 17. März 2003 15:31 $ An: [EMAIL PROTECTED] $ Betreff: SV: Embedding fonts! $ $ $ No, I didn't. Should I have done that? $ $ /Uwe $ $ -Ursprungligt meddelande- $ Från: Müller, Markus [mailto:[EMAIL PROTECTED] $ Skickat: den 17 mars 2003 11:40 $ Till: [EMAIL PROTECTED] $ Ämne: AW: Embedding fonts! $ $ Hi, $ $ How did you create the font metrics files? Did you use the $ option -enc $ ansi ? $ $ Markus $ $ $ -Ursprüngliche Nachricht- $ $ Von: Uwe Klosa [mailto:[EMAIL PROTECTED] $ $ Gesendet: Montag, 17. März 2003 11:33 $ $ An: [EMAIL PROTECTED]; [EMAIL PROTECTED] $ $ Betreff: Embedding fonts! $ $ $ $ $ $ Hi, $ $ $ $ I'm using embedded fonts in fop. That is working fine. But $ $ if I want to edit $ $ the resulting pdf files with Acrobat, the font names aren't $ $ correct in the $ $ file. I'm getting 1Eec24TimesNewRoman or 2Ef1d7TimesNewRoman $ $ where it should $ $ be TimesNewRoman. Why creates fop theses font names? Has $ $ anyone tried do $ $ edit the resulting pdf files? $ $ $ $ Regards Uwe $ $ $ $ $ $ $ - $ $ To unsubscribe, e-mail: [EMAIL PROTECTED] $ $ For additional commands, email: [EMAIL PROTECTED] $ $ $ $ - $ To unsubscribe, e-mail: [EMAIL PROTECTED] $ For additional commands, email: [EMAIL PROTECTED] $ $ $ - $ To unsubscribe, e-mail: [EMAIL PROTECTED] $ For additional commands, email: [EMAIL PROTECTED] $ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Embedding fonts!
Hi, I'm using embedded fonts in fop. That is working fine. But if I want to edit the resulting pdf files with Acrobat, the font names aren't correct in the file. I'm getting 1Eec24TimesNewRoman or 2Ef1d7TimesNewRoman where it should be TimesNewRoman. Why creates fop theses font names? Has anyone tried do edit the resulting pdf files? Regards Uwe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
AW: Embedding fonts!
Hi, How did you create the font metrics files? Did you use the option -enc ansi ? Markus $ -Ursprüngliche Nachricht- $ Von: Uwe Klosa [mailto:[EMAIL PROTECTED] $ Gesendet: Montag, 17. März 2003 11:33 $ An: [EMAIL PROTECTED]; [EMAIL PROTECTED] $ Betreff: Embedding fonts! $ $ $ Hi, $ $ I'm using embedded fonts in fop. That is working fine. But $ if I want to edit $ the resulting pdf files with Acrobat, the font names aren't $ correct in the $ file. I'm getting 1Eec24TimesNewRoman or 2Ef1d7TimesNewRoman $ where it should $ be TimesNewRoman. Why creates fop theses font names? Has $ anyone tried do $ edit the resulting pdf files? $ $ Regards Uwe $ $ $ - $ To unsubscribe, e-mail: [EMAIL PROTECTED] $ For additional commands, email: [EMAIL PROTECTED] $ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
SV: Embedding fonts!
No, I didn't. Should I have done that? /Uwe -Ursprungligt meddelande- Från: Müller, Markus [mailto:[EMAIL PROTECTED] Skickat: den 17 mars 2003 11:40 Till: [EMAIL PROTECTED] Ämne: AW: Embedding fonts! Hi, How did you create the font metrics files? Did you use the option -enc ansi ? Markus $ -Ursprüngliche Nachricht- $ Von: Uwe Klosa [mailto:[EMAIL PROTECTED] $ Gesendet: Montag, 17. März 2003 11:33 $ An: [EMAIL PROTECTED]; [EMAIL PROTECTED] $ Betreff: Embedding fonts! $ $ $ Hi, $ $ I'm using embedded fonts in fop. That is working fine. But $ if I want to edit $ the resulting pdf files with Acrobat, the font names aren't $ correct in the $ file. I'm getting 1Eec24TimesNewRoman or 2Ef1d7TimesNewRoman $ where it should $ be TimesNewRoman. Why creates fop theses font names? Has $ anyone tried do $ edit the resulting pdf files? $ $ Regards Uwe $ $ $ - $ To unsubscribe, e-mail: [EMAIL PROTECTED] $ For additional commands, email: [EMAIL PROTECTED] $ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/fonts LazyFont.java
jeremias2003/03/15 08:50:56
Modified:src/java/org/apache/fop/fonts LazyFont.java
Log:
Log problems during font loading to System.out for the moment until proper logging
is in place.
Revision ChangesPath
1.2 +1 -0 xml-fop/src/java/org/apache/fop/fonts/LazyFont.java
Index: LazyFont.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/fonts/LazyFont.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- LazyFont.java 11 Mar 2003 13:05:15 - 1.1
+++ LazyFont.java 15 Mar 2003 16:50:56 - 1.2
@@ -96,6 +96,7 @@
}
// System.out.println(Metrics + metricsFileName + loaded.);
} catch (Exception ex) {
+ex.printStackTrace();
/[EMAIL PROTECTED] Log this exception */
//log.error(Failed to read font metrics file
// + metricsFileName
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17921] New: - Kerning is broken for standard fonts
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=17921. 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=17921 Kerning is broken for standard fonts Summary: Kerning is broken for standard fonts Product: Fop Version: 0.20.4 Platform: PC OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The kerning tables are bad for the standard fonts. When creating font metrics for user specified fonts, I found that I need to use the -enc ansi or else the user specified font has the same problem. The default CID encoding created key indices that were off. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17921] - Kerning is broken for standard fonts
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=17921. 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=17921 Kerning is broken for standard fonts --- Additional Comments From [EMAIL PROTECTED] 2003-03-12 18:10 --- Yes, the problem still exists in 0.20.5rc2. At least TTFReader gave me the same incorrect values as before for the font metrics, I did not create a document though. Sorry, I was not aware that the standard fonts did not have kerning info. I asssumed it was the same problem I had with user defined fonts. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/fonts/type1 - New directory
jeremias2003/03/11 04:52:22 xml-fop/src/java/org/apache/fop/fonts/type1 - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/fonts - New directory
jeremias2003/03/11 04:52:20 xml-fop/src/java/org/apache/fop/fonts - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/fonts/apps - New directory
jeremias2003/03/11 04:52:20 xml-fop/src/java/org/apache/fop/fonts/apps - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/java/org/apache/fop/fonts/truetype - New directory
jeremias2003/03/11 04:52:22 xml-fop/src/java/org/apache/fop/fonts/truetype - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
