You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Dorothea Wiarda <wi...@vic.com> on 2000/11/07 18:42:18 UTC
AWTRenderer
I have been looking through the AWTRenderer in my endeavour to
understand the code. The AWTRenderer prints a preview that has words
runnung into one another due to different font-metrics for AWT and PDF.
If the following changes
are made, that can be avoided, at the cost of worse looking text.
However, at least it would look more like a previewer. It can also do
underlined text.
Doro
----- diff for org.apache.fop.renderer.awt.AWTRenderer----------------
*** AWTRenderer.java Tue Nov 7 17:28:21 2000
--- AWTRenderer.java.save Tue Nov 7 17:17:45 2000
***************
*** 27,33 ****
import java.awt.image.*;
import java.awt.geom.*;
import java.awt.font.*;
- import java.text.*;
import java.util.*;
import java.net.URL;
import java.net.MalformedURLException;
--- 27,32 ----
***************
*** 64,74 ****
private Graphics2D graphics = null;
/**
- * Used to make the text fit
- */
- private AffineTransform affine = new AffineTransform();
-
- /**
* The current (internal) font name
*/
protected String currentFontName;
--- 63,68 ----
***************
*** 514,520 ****
String name = area.getFontState().getFontName();
int size = area.getFontState().getFontSize();
- boolean underlined=area.getUnderlined();
float red = area.getRed();
float green = area.getGreen();
--- 508,513 ----
***************
*** 560,581 ****
// Fonts in bold still have trouble displaying!
FontRenderContext newContext = new FontRenderContext(null, true,
true);
! AttributedString ats=new AttributedString(s);
! ats.addAttribute(TextAttribute.FONT, f);
! if(underlined){
! ats.addAttribute(TextAttribute.UNDERLINE,
! TextAttribute.UNDERLINE_ON);
! }
! AttributedCharacterIterator iter=ats.getIterator();
! TextLayout layout=new TextLayout(iter, newContext);
graphics.setRenderingHint(RenderingHints.KEY_RENDERING,
RenderingHints.VALUE_RENDER_QUALITY);
! affine.setTransform(
!
area.getContentWidth()/(layout.getVisibleAdvance()*1000f) ,
! 0 , 0,
! 1.0 , rx / 1000f, (int)(pageHeight - bl / 1000f) );
! Shape shape = layout.getOutline(affine);
! graphics.fill(shape);
graphics.setColor(oldColor);
this.currentXPosition += area.getContentWidth();
--- 553,562 ----
// Fonts in bold still have trouble displaying!
FontRenderContext newContext = new FontRenderContext(null, true,
true);
! TextLayout layout = new TextLayout(s, f, newContext);
graphics.setRenderingHint(RenderingHints.KEY_RENDERING,
RenderingHints.VALUE_RENDER_QUALITY);
! layout.draw(graphics, rx / 1000f, (int)(pageHeight - bl / 1000f));
graphics.setColor(oldColor);
this.currentXPosition += area.getContentWidth();
----------------------------------------------------------------------
--
________________________________________________________
Dorothea Wiarda
E-Mail: wiarda@dwiarda.com
Web-Home: http://www.dwiarda.com
http://www.techno-info.com
Re: AWTRenderer
Posted by Stephan Albers <St...@jcatalog.com>.
Fotis Jannidis schrieb:
> I noticed that it can be rather troublesome if your file has many area
> overflows. Maybe you could route them to the status too? And if you
> are at the error message, maybe it would be a good idea to make
> sure that one line of an error message isn't more than 60 char, so it
> looks better and no error text is lost?
That would be great.
> I think your approach to make AWTCommandLine a GUI tool without
> any reliance on the commandline window is a good idea. So
> probably removing the line
> MessageHandler.errorln(Version.getVersion());
> from AWTCommandLine would be ok.
The AWTCommandline was introduced just to be compliant with PDF, same
was true for error/status. Having a "full" GUI tool would be great.
Stephan
Re: AWTRenderer
Posted by Dorothea Wiarda <wi...@vic.com>.
Fotis and Stephan:
thanks for all the comments. It is certainly fun to get feedback that
quickly.
I will first comment on Fotis questions:
1) I routed ">" errors to the status bar and ignored empty errors.
2) The error message now gets putinto several lines, each no longer
that 60 characters or one word (i.e. if there is a word which is longer
than 60 characters it gets put into a line by itself).
Concerning the non-showing bullets in list2.fo:
The bullets come from the Symbol font. The Symbol font is mapped to
java Symbol. However, if you look at fonts.fo with AWTRenderer and
PDFRenderer, you will see that the symbols are not the same. For my
set-up, the round nice bullet for symbols in the pdf font is a puny
little dot with AWTRenderer.
>Btw, in the long run it would be cleaner to have a class
>FopWarnings with different warnings (which could be
>internationalized easier that way too) concerning non fatal errors in
>the fo file and then AWTCommandLine could check for the warning
>type and act accordingly. Maybe I can change MessageHandler
>etc. in the next months for this.
Yes, I think it would be nice to have log, warning and error options in
MessageHandler. It would probably also be nice to add the option to
write a log file in addition or instead of (per flag) of writting to the
screen or generating errors. If that log file is marked up correctly,
the AWTRenderer could have an extra option: Show log, where for example
log events are in black, error in red and warnings in green. Or some
such thing.
Now to Stephan's comments:
>Sorry if this sounds braindead, but when I first saw the problems with
>merged letters/bold, I thought there would be a difference between Java
>Fonts and OS fonts. But in Java 1.2.2 there are tons of methods dealing
>with fonts, glyphs etc. all based upon the font metrics of the OS (at
>least for windows). On a windows system we can also access all fonts
>that are installed locally. My question is: for Helvetica etc. are there
>difference between the typical OS fonts and the default PDF fonts
>concerning their metrics. If not, the output should always be the same.
GraphicsContext.getAllFonts() also lists tons of installed PostScript
fonts on my machine. But they are different fonts than on Windows. I
picked SansSerif, Serif and Symbol because the JDK API says those are
among the fonts that have to be always there. I think however, that a
better font-choice can be made in FontSetup.java. What I wanted to
achieve of course is that all font selection is done in FontSetup.java.
There are indeed tons of metric methods, however most deal with whole
strings or entire sentences. The layout methods in FOP rely on measuring
the width of strings by adding the width of the different characters.
That is why I did it the way I did. However, all fontmetric stuff
should be isolated in AWTFontMetrics and should thus be easy to change.
AWTRenderer would thus never know how to choose the correct font, it
just asks FontMetricsMapper to hand it one.
.
Also we first had the following idea concerning alternative fonts:
instead of parsing the external metric file, why not use the
metrice/glyph methods that Java has to create the font metrics (works
only with Java 2).
This might still work. I thought about this too. However they would have
to be created upon install time as they are probably different for each
system. Also, it probably would not work as nicely as for the Type 1
fonts as the standard Java fonts don't scale with fontsize.
The attached patch is against todays CVS tree and fixes points 1) and 2)
mentioned above.
Also add FontSetup.java, FontMetricsMapper.java and AWTFontMetrics.java
into src/org/apache/fop/render/awt.
The only changes I did from the last patch.txt I send you are in
PreviewDialog.java.
Doro
--
________________________________________________________
Dorothea Wiarda
E-Mail: wiarda@dwiarda.com
Web-Home: http://www.dwiarda.com
http://www.techno-info.com
Re: AWTRenderer
Posted by Fotis Jannidis <fo...@lrz.uni-muenchen.de>.
> Doro:
> I will chop up the error messages later today or tomorrow (EST). I
> thought about the area overflow too, but did not know what is the best
> way to solve it. Maybe we could reroute the error message if it is ">"
> or empty. This way a lot of the JOPtionPanes would go away. Would that
> be okay?
Yes, that seems to me the quick solution.
Btw, in the long run it would be cleaner to have a class
FopWarnings with different warnings (which could be
internationalized easier that way too) concerning non fatal errors in
the fo file and then AWTCommandLine could check for the warning
type and act accordingly. Maybe I can change MessageHandler
etc. in the next months for this.
Don't you think, empty error messages or ones only containing
spaces could be discarded completely?
Fotis
Re: AWTRenderer
Posted by Dorothea Wiarda <wi...@vic.com>.
Fotis Jannidis wrote:
>
> Hi,
>
> I have patched my files and I am ready to commit your stuff, if I
> don't hear some veto from Stephan/Stanislav.
>
Thank you
> I noticed that it can be rather troublesome if your file has many area
> overflows. Maybe you could route them to the status too? And if you
> are at the error message, maybe it would be a good idea to make
> sure that one line of an error message isn't more than 60 char, so it
> looks better and no error text is lost?
>
I will chop up the error messages later today or tomorrow (EST). I
thought about the area overflow too, but did not know what is the best
way to solve it. Maybe we could reroute the error message if it is ">"
or empty. This way a lot of the JOPtionPanes would go away. Would that
be okay?
> If you view the new test file list2.fo, you will notice that the bullet isn't
> showing. Is there a way to circumvent this? (Very obviously fonts
> are not platform independent).
>
I will look at that.
> I think your approach to make AWTCommandLine a GUI tool without
> any reliance on the commandline window is a good idea. So
> probably removing the line
> MessageHandler.errorln(Version.getVersion());
> from AWTCommandLine would be ok.
>
> Fotis
Thanks for the comments
Doro
--
________________________________________________________
Dorothea Wiarda
E-Mail: wiarda@dwiarda.com
Web-Home: http://www.dwiarda.com
http://www.techno-info.com
Re: AWTRenderer
Posted by Fotis Jannidis <fo...@lrz.uni-muenchen.de>.
Hi,
I have patched my files and I am ready to commit your stuff, if I
don't hear some veto from Stephan/Stanislav.
I noticed that it can be rather troublesome if your file has many area
overflows. Maybe you could route them to the status too? And if you
are at the error message, maybe it would be a good idea to make
sure that one line of an error message isn't more than 60 char, so it
looks better and no error text is lost?
If you view the new test file list2.fo, you will notice that the bullet isn't
showing. Is there a way to circumvent this? (Very obviously fonts
are not platform independent).
I think your approach to make AWTCommandLine a GUI tool without
any reliance on the commandline window is a good idea. So
probably removing the line
MessageHandler.errorln(Version.getVersion());
from AWTCommandLine would be ok.
Fotis
Re: AWTRenderer
Posted by Dorothea Wiarda <wi...@vic.com>.
Hi,
I put all the changes I have made to get AWTRenderer to work so so
(limitations see earlier mails) in one patch.txt file.
One also needs to put the FontSetup.java FontMetricsMapper.java
AWTFontMetrics.java into the
org.apache.fop.renderer.awt directory.
I had to remove the entire build directory before I was able to have it
to compile and to include the changes in src/codegen.
The patch includes changes to org.apache.fop.layout.FontMetrics and
org.apache.fop.layout.FontState to handle the scaling of the AWT fonts
(which alas do not scale as Type 1 fonts).
The patch also includes the piping of the error and log output of
MessageHandler to the status bar of the AWTPreviewer. Where is the last
empty error-message generated? If we want to include the piping, I will
go hunting for that error message.
Also, to ensure that the AWT font-metric parameters are mapped to the
Type 1 font-metrics parameters I plotted the length of these measures
for all the latein letters. The result files can be viewed at
http://www.dwiarda.com/ORCMA/fop
All are pdf files, the first part of the name gives the Font-Metrics
characteristic, the second whether created by AWTRenderer or
PDFRenderer. You should be able to get a directory listing.
The patch is against the CVS-tree of this morning.
Doro
________________________________________________________
Dorothea Wiarda
E-Mail: wiarda@dwiarda.com
Web-Home: http://www.dwiarda.com
http://www.techno-info.com
RE: AWTRenderer
Posted by Fotis Jannidis <fo...@lrz.uni-muenchen.de>.
I think AWTRenderer should be an renderer in its own rights, so the
dependence on the PDFRenderer should disappear - especially as
you can use the AWTRenderer to print your document.
Your ideas look good to me and would make the design of the
AWTRenderer parallel to that of PDFRenderer. You would change
AWTRenderer.setupFontInfo() to point to the 'dummy' fontmetrics
class. Do you say 'dummy', because it won't contain any hard wired
font info, but generates the information dynamically, so the
information is correct on each user platform?
Instead of java.awt.Font.getStringBounds() you could also use
java.awt.font.LineMetrics.
Maybe the reference to
org.apache.fop.render.pdf.CodePointMapping.map[c];
in LineArea.addText() has to be changed then too (There is a memo
there already: /* this class shouldn't be hard coded */
Fotis
> We are using the AWTRenderer as a renderer in its own right. We have
> embedded it in an experimental XML browser. That is why we, at least, need
> to patch the AWTRenderer to use java's FontMetrics instead of PDF
> fontmetrics.
>
> Looking at the code it seems that layout.LineArea.addText() calls
> FontState.width(char) for each character.
>
> FontState uses FontInfo.getMetricFor(fontName) to get the metrix class and
> then calls calculates fontSize * metric.width(charnum) to get the characters
> width.
>
> So maybe what would be needed would be a dummy AWTFontMetrics which would
> use java.awt.Font.getStringBounds() or similar to return character widths.
> Any ideas?
>
> -----Original Message-----
> From: dwiarda@gatekeeper.vic.com [mailto:dwiarda@gatekeeper.vic.com]On
> Behalf Of Dorothea Wiarda
> Sent: 8. marraskuuta 2000 11:56
> To: fop-dev@xml.apache.org
> Cc: Mikko Honkala
> Subject: Re: AWTRenderer
>
> I am sure there is a way to change the font-metrics in the AWTRenderer,
> using the AWT FontMetrics class
> or something along this line. I am willing to look at that - it
> shouldn't be too hard. However, there is another question connected with
> that. Is the AWTRenderer a renderer in its own right, in which case the
> FontMetrics needs to be fixed or is it a Previewer. If it is a
> Previewer, than it should use the PDF FontMetrics, even for the prize of
> an ugly looking font (and I know it looks ugly), so that one gets the
> same line and page breaks as in the PDF.
>
> What is the general philosophy concerning this matter?
>
RE: AWTRenderer
Posted by Mikko Honkala <Mi...@iki.fi>.
We are using the AWTRenderer as a renderer in its own right. We have
embedded it in an experimental XML browser. That is why we, at least, need
to patch the AWTRenderer to use java's FontMetrics instead of PDF
fontmetrics.
Looking at the code it seems that layout.LineArea.addText() calls
FontState.width(char) for each character.
FontState uses FontInfo.getMetricFor(fontName) to get the metrix class and
then calls calculates fontSize * metric.width(charnum) to get the characters
width.
So maybe what would be needed would be a dummy AWTFontMetrics which would
use java.awt.Font.getStringBounds() or similar to return character widths.
Any ideas?
-----Original Message-----
From: dwiarda@gatekeeper.vic.com [mailto:dwiarda@gatekeeper.vic.com]On
Behalf Of Dorothea Wiarda
Sent: 8. marraskuuta 2000 11:56
To: fop-dev@xml.apache.org
Cc: Mikko Honkala
Subject: Re: AWTRenderer
I am sure there is a way to change the font-metrics in the AWTRenderer,
using the AWT FontMetrics class
or something along this line. I am willing to look at that - it
shouldn't be too hard. However, there is another question connected with
that. Is the AWTRenderer a renderer in its own right, in which case the
FontMetrics needs to be fixed or is it a Previewer. If it is a
Previewer, than it should use the PDF FontMetrics, even for the prize of
an ugly looking font (and I know it looks ugly), so that one gets the
same line and page breaks as in the PDF.
What is the general philosophy concerning this matter?
Re: AWTRenderer
Posted by Dorothea Wiarda <wi...@vic.com>.
Mikko Honkala wrote:
>
> Hi!
>
> I tried your approach, and as you said, it fixed the overlapping
> words-problem in the AWTRenderer, but the text became much worse. I think
> this is because
>
> Shape shape = layout.getOutline(affine);
>
> returns a shape object, which is then rendered to the graphics.
>
> Would there be a way to change the font-metrics in the AWT mode so that we
> wouldn't need to do the affine transform in the renderer? Could you give me
> more details of the root cause of the problem?
>
I am sure there is a way to change the font-metrics in the AWTRenderer,
using the AWT FontMetrics class
or something along this line. I am willing to look at that - it
shouldn't be too hard. However, there is another question connected with
that. Is the AWTRenderer a renderer in its own right, in which case the
FontMetrics needs to be fixed or is it a Previewer. If it is a
Previewer, than it should use the PDF FontMetrics, even for the prize of
an ugly looking font (and I know it looks ugly), so that one gets the
same line and page breaks as in the PDF.
What is the general philosophy concerning this matter?
Doro
________________________________________________________
Dorothea Wiarda
E-Mail: wiarda@dwiarda.com
Web-Home: http://www.dwiarda.com
http://www.techno-info.com
RE: AWTRenderer
Posted by Mikko Honkala <Mi...@iki.fi>.
Hi!
I tried your approach, and as you said, it fixed the overlapping
words-problem in the AWTRenderer, but the text became much worse. I think
this is because
Shape shape = layout.getOutline(affine);
returns a shape object, which is then rendered to the graphics.
Would there be a way to change the font-metrics in the AWT mode so that we
wouldn't need to do the affine transform in the renderer? Could you give me
more details of the root cause of the problem?
-----Original Message-----
From: dwiarda@gatekeeper.vic.com [mailto:dwiarda@gatekeeper.vic.com]On
Behalf Of Dorothea Wiarda
Sent: 7. marraskuuta 2000 19:42
To: fop-dev@xml.apache.org
Subject: AWTRenderer
I have been looking through the AWTRenderer in my endeavour to
understand the code. The AWTRenderer prints a preview that has words
runnung into one another due to different font-metrics for AWT and PDF.
If the following changes
are made, that can be avoided, at the cost of worse looking text.
However, at least it would look more like a previewer. It can also do
underlined text.