Re: Dramatic improvement of PDF text painting quality for SVG
On 05.11.2007 08:22:38 Max Berger wrote: Jeremias, Am Samstag, den 03.11.2007, 12:22 +0100 schrieb Jeremias Maerki: Implementation notes: - The text painter has a fallback so it can still paint text with SVG fonts. Text for which there's no font in FOP's FontInfo object will be painted using shapes as before. Please correct me if I'm wrong: AFAIK fop does not embed fonts into the document unless explicitly requested. So with the new auto-detection feature, it will automatically pick up all fonts on the local system, and provide font-metrics (FontInfo) for it, but not embed them. No, it does embed them by default! I think we don't have a facility to suppress font embedding for auto-detected fonts, yet. If the resulting pdf is moved to a different machine where the installed font set is different, the result will look very garbled. No, it doesn't affect the resulting PDF because the fonts are embedded. Feedback welcome. And yes, XSL-FO documents with embedded SVG profit from these changes, too. :-) Have fun! Jeremias Maerki Max Jeremias Maerki
Re: svn commit: r591583 - in /xmlgraphics/fop/trunk/src: codegen/fonts/ java/org/apache/fop/fonts/ java/org/apache/fop/pdf/
Hi Jeremias,
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/Typeface.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/Typeface.java?rev=591583r1=591582r2=591583view=diff
==
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/Typeface.java
(original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/Typeface.java Sat Nov
3 03:51:31 2007
@@ -27,6 +27,8 @@
*/
public abstract class Typeface implements FontMetrics {
+private long charMapOps = 0;
+
/**
* Get the encoding of the font.
* @return the encoding
@@ -39,6 +41,23 @@
* @return the mapped character
*/
public abstract char mapChar(char c);
+
+/**
+ * Used for keeping track of character mapping operations in order to
determine if a font
+ * was used at all or not.
+ */
+protected void notifyMapOperation() {
+this.charMapOps++;
+}
+
+/**
+ * Indicates whether this font had to do any character mapping
operations. If that was
+ * not the case, it's an indication that the font has never actually
been used.
+ * @return true if the font had to do any character mapping operations
+ */
+public boolean hadMappingOperations() {
+return (this.charMapOps 0);
+}
Basically you need to know whether the font has been used or not. Then
why not just use a boolean for charMapOps?
Vincent
Re: svn commit: r591583 - in /xmlgraphics/fop/trunk/src: codegen/fonts/ java/org/apache/fop/fonts/ java/org/apache/fop/pdf/
Statistical interest. Increasing a long shouldn't use many more CPU
cycles than setting a boolean to true, right?
Jeremias Maerki
On 05.11.2007 11:32:09 Vincent Hennebert wrote:
Hi Jeremias,
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/Typeface.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/Typeface.java?rev=591583r1=591582r2=591583view=diff
==
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/Typeface.java
(original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/Typeface.java Sat
Nov 3 03:51:31 2007
@@ -27,6 +27,8 @@
*/
public abstract class Typeface implements FontMetrics {
+private long charMapOps = 0;
+
/**
* Get the encoding of the font.
* @return the encoding
@@ -39,6 +41,23 @@
* @return the mapped character
*/
public abstract char mapChar(char c);
+
+/**
+ * Used for keeping track of character mapping operations in order to
determine if a font
+ * was used at all or not.
+ */
+protected void notifyMapOperation() {
+this.charMapOps++;
+}
+
+/**
+ * Indicates whether this font had to do any character mapping
operations. If that was
+ * not the case, it's an indication that the font has never actually
been used.
+ * @return true if the font had to do any character mapping operations
+ */
+public boolean hadMappingOperations() {
+return (this.charMapOps 0);
+}
Basically you need to know whether the font has been used or not. Then
why not just use a boolean for charMapOps?
Vincent
Re: svn commit: r591583 - in /xmlgraphics/fop/trunk/src: codegen/fonts/ java/org/apache/fop/fonts/ java/org/apache/fop/pdf/
Jeremias Maerki wrote: Statistical interest. Increasing a long shouldn't use many more CPU cycles than setting a boolean to true, right? That’s not a problem of performance. When I see this I simply wonder why a long is used while a boolean would be sufficient. Statistical interest, why not, although here it only exists when doing a manual debugging session. That’s not a very big deal anyway since here the class is small, but when you encounter such variables in hundreds of other lines of codes, believe me, it takes a while before figuring out that they are actually used as booleans... A small comment, perhaps? Vincent
Re: svn commit: r591587 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/render/ps/ src/java/org/apache/fop/svg/
Hi Jeremias,
I’d have a couple of comments regarding your changes. I’ve only had
a quick look and don’t understand this part of the code well, but
following the principle of pair review, here they are:
- at several places there is code like the following:
private void checkInTextObject() {
if (!inTextObject) {
throw new IllegalStateException(Not in text object);
}
}
I understand and don’t criticise the need for safety checks,
especially if the code is new or complex. Only, since we now have
Java 1.4 as a minimal requirement, why not use assert statements? They
were created exactly for that.
- in PDFTextUtil:
- the setTextRenderingMode(int) method is only used within
PDFTextUtil; why then not making it private? The other
setTextRenderingMode method will still be available and seems to be
much safer to use anyway.
- it seems to me that a bit more of the internal state of
a PDFTextUtil object could be controlled by the object itself,
especially in the following piece of code (PDFTextPainter, l.220):
Font f = textUtil.selectFontForChar(ch);
if (f != textUtil.getCurrentFont()) {
textUtil.writeTJ();
textUtil.setCurrentFont(f);
textUtil.writeTf(f);
textUtil.writeTextMatrix(localTransform);
}
A signalFontUsed(f) method might make sense. Basically doing the
same test as above, but inside PDFTextUtil. The code would be better
encapsulated, so more maintainable. WDYT?
- in PDFTextPainter: now that the code is working, you probably want to
remove the DEBUG variable and all the statements displaying stuff to
System.out; or replace them with proper log.debug statements ;-)
For the rest I believe when you say it’s working... Congrats!
Vincent
Re: svn commit: r591587 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/render/ps/ src/java/org/apache/fop/svg/
On 05.11.2007 13:05:29 Vincent Hennebert wrote:
Hi Jeremias,
I’d have a couple of comments regarding your changes. I’ve only had
a quick look and don’t understand this part of the code well, but
following the principle of pair review, here they are:
- at several places there is code like the following:
private void checkInTextObject() {
if (!inTextObject) {
throw new IllegalStateException(Not in text object);
}
}
I understand and don’t criticise the need for safety checks,
especially if the code is new or complex. Only, since we now have
Java 1.4 as a minimal requirement, why not use assert statements? They
were created exactly for that.
I could do a lot of stuff. I'm so used to working pre-Java-1.4 that it
didn't occur to me. Feel free to change. There's no code-ownership in
Apache projects.
- in PDFTextUtil:
- the setTextRenderingMode(int) method is only used within
PDFTextUtil; why then not making it private? The other
setTextRenderingMode method will still be available and seems to be
much safer to use anyway.
PDFTextUtil is designed to be useful for classes other than
PDFTextPainter. Someone might prefer working more closely to the PDF
spec and therefore prefer the int variant.
- it seems to me that a bit more of the internal state of
a PDFTextUtil object could be controlled by the object itself,
especially in the following piece of code (PDFTextPainter, l.220):
Font f = textUtil.selectFontForChar(ch);
if (f != textUtil.getCurrentFont()) {
textUtil.writeTJ();
textUtil.setCurrentFont(f);
textUtil.writeTf(f);
textUtil.writeTextMatrix(localTransform);
}
A signalFontUsed(f) method might make sense. Basically doing the
same test as above, but inside PDFTextUtil. The code would be better
encapsulated, so more maintainable. WDYT?
Again, feel free to change and improve.
- in PDFTextPainter: now that the code is working, you probably want to
remove the DEBUG variable and all the statements displaying stuff to
System.out; or replace them with proper log.debug statements ;-)
No, I don't. The debug code is most probably optimized away by the
compiler so it doesn't bother us at runtime. If any bugs arise, it's
convenient to switch on. Most importantly, though, the Batik guys have
indicated that they don't want to work with a logging framework. Since
this code is destined to go to Batik I try not to introduce more Commons
Logging in this area.
For the rest I believe when you say it’s working... Congrats!
Vincent
Jeremias Maerki
Re: svn commit: r591587 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/render/ps/ src/java/org/apache/fop/svg/
Jeremias Maerki wrote:
snip/
- it seems to me that a bit more of the internal state of
a PDFTextUtil object could be controlled by the object itself,
especially in the following piece of code (PDFTextPainter, l.220):
Font f = textUtil.selectFontForChar(ch);
if (f != textUtil.getCurrentFont()) {
textUtil.writeTJ();
textUtil.setCurrentFont(f);
textUtil.writeTf(f);
textUtil.writeTextMatrix(localTransform);
}
A signalFontUsed(f) method might make sense. Basically doing the
same test as above, but inside PDFTextUtil. The code would be better
encapsulated, so more maintainable. WDYT?
Again, feel free to change and improve.
Ok. It’s just that I’m reluctant to modify code I’m not familiar with,
and from which I may have missed the logic.
- in PDFTextPainter: now that the code is working, you probably want to
remove the DEBUG variable and all the statements displaying stuff to
System.out; or replace them with proper log.debug statements ;-)
No, I don't. The debug code is most probably optimized away by the
compiler so it doesn't bother us at runtime. If any bugs arise, it's
Except if the DEBUG variable is left to true...
convenient to switch on. Most importantly, though, the Batik guys have
indicated that they don't want to work with a logging framework. Since
this code is destined to go to Batik I try not to introduce more Commons
Logging in this area.
Vincent
Re: svn commit: r591587 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/render/ps/ src/java/org/apache/fop/svg/
On 05.11.2007 15:37:29 Vincent Hennebert wrote: snip/ - in PDFTextPainter: now that the code is working, you probably want to remove the DEBUG variable and all the statements displaying stuff to System.out; or replace them with proper log.debug statements ;-) No, I don't. The debug code is most probably optimized away by the compiler so it doesn't bother us at runtime. If any bugs arise, it's Except if the DEBUG variable is left to true... Oh, that was a mistake. I thought I switched it to false. Thanks for correcting it. snip/ Jeremias Maerki
First steps towards an implementation for fo:inline-container
Hi people
I've recently (finally) started looking at implementing fo:inline-
container, and got to my first promising results, so just thought I'd
share, should there be any interested parties.
OTOH, I've also run into a few obstacles I'm unsure how to deal with,
so...
The rough InlineContainerLayoutManager implementation I have now
still descends from LeafNodeLayoutManager. No idea if that's going to
be enough in the long run, but for now I did manage to get some
simple examples working without changing this.
The generation of the element list is no particular problem.
Basically the same as blocks in an fo:inline, only slightly simpler
because the inline-container can /only/ contain block-sequences, and
as such there is no need to worry about closing any open paragraphs.
So far I only got it working for a sequence of one or more fo:blocks,
though. The sequences returned for an fo:table or an fo:list-block
seem to confuse the LineBreakingAlgorithm for the containing Block
once the inline table/list contains more than one row/item. Haven't
looked too deep into that, but it seems to be something like: the
algorithm expects to find a KnuthElement, but finds something else (a
KnuthSequence, probably = ClassCastException in
BreakingAlgorithm.getElement()).
ATM, in the basic getNextKnuthElements(), little more happens than:
KnuthSequence inlineSequence = new InlineKnuthSequence();
...
while (curLM ...) {
...
returnedList = curLM.getNextKnuthElements(...);
...
KnuthSequence tmpSeq = new BlockKnuthSequence(returnedList);
seq.wrapPositions(this);
inlineSeq.addAll(seq);
}
Qua area-generation, it is set up as a viewport/reference area pair,
where the viewport is the same Viewport type used for the images and
the reference-area is an InlineBlockParent.
Currently, I still sort of hacked the structure together:
* the reference-area has a single Block child that is used to add the
childAreas to
* at the end of the addAreas() loop, the viewport's content is set to
the reference-area
Maybe it would be slightly better to allow InlineBlockParent to have
multiple children, but for now, inserting that dummy Block seemed the
least intrusive way of reaching the goal.
Anyways, a small addition to cater for rendering an InlineBlockParent
in AbstractRenderer.renderViewport() did the rest.
One of the obstacles I'm running into now, and I'm hoping someone
might be able to provide pointers for, is adjusting the line-height.
See the attachment, where the inner blocks already appear nicely in
position, but the following line still overlaps. :(
It's not ready for a commit yet, but I do hope to get it in a more
usable state soon, so we can finally claim support for the XSL-FO
equivalent of HTML's IFRAME.
Cheers
Andreas
test.at.pdf
Description: Adobe PDF document
Re: svn commit: r591583 - in /xmlgraphics/fop/trunk/src: codegen/fonts/ java/org/apache/fop/fonts/ java/org/apache/fop/pdf/
On Nov 5, 2007, at 12:42, Vincent Hennebert wrote: Jeremias Maerki wrote: Statistical interest. Increasing a long shouldn't use many more CPU cycles than setting a boolean to true, right? That’s not a problem of performance. When I see this I simply wonder why a long is used while a boolean would be sufficient. Statistical interest, why not, although here it only exists when doing a manual debugging session. That’s not a very big deal anyway since here the class is small, but when you encounter such variables in hundreds of other lines of codes, believe me, it takes a while before figuring out that they are actually used as booleans... True, or should I say 'one' :-) Funny, this description somehow reminds me of the times when I familiarized myself with the good old Win32 API... ;-) Cheers Andreas
Re: First steps towards an implementation for fo:inline-container
Very cool, Andreas! Actually, I don't see why you shouldn't commit what
you have if it is a step forward an inline-container was basically
unusable before.
About your question (probably not very helpful): I'm not sure (Manuel is
our baseline master) but why don't you take a look at
AbstractGraphicsLayoutManager? external-graphic and i-f-o both generate
a viewport/reference pair. I suspect that you simply have to provide a
makeAlignmentContext(LayoutContext) method. Figuring out the right
values there (given the baseline instructions for i-c) is another story,
I guess. But one step at a time...
HTH
Jeremias Maerki
On 05.11.2007 21:18:14 Andreas L Delmelle wrote:
Hi people
I've recently (finally) started looking at implementing fo:inline-
container, and got to my first promising results, so just thought I'd
share, should there be any interested parties.
OTOH, I've also run into a few obstacles I'm unsure how to deal with,
so...
The rough InlineContainerLayoutManager implementation I have now
still descends from LeafNodeLayoutManager. No idea if that's going to
be enough in the long run, but for now I did manage to get some
simple examples working without changing this.
The generation of the element list is no particular problem.
Basically the same as blocks in an fo:inline, only slightly simpler
because the inline-container can /only/ contain block-sequences, and
as such there is no need to worry about closing any open paragraphs.
So far I only got it working for a sequence of one or more fo:blocks,
though. The sequences returned for an fo:table or an fo:list-block
seem to confuse the LineBreakingAlgorithm for the containing Block
once the inline table/list contains more than one row/item. Haven't
looked too deep into that, but it seems to be something like: the
algorithm expects to find a KnuthElement, but finds something else (a
KnuthSequence, probably = ClassCastException in
BreakingAlgorithm.getElement()).
ATM, in the basic getNextKnuthElements(), little more happens than:
KnuthSequence inlineSequence = new InlineKnuthSequence();
...
while (curLM ...) {
...
returnedList = curLM.getNextKnuthElements(...);
...
KnuthSequence tmpSeq = new BlockKnuthSequence(returnedList);
seq.wrapPositions(this);
inlineSeq.addAll(seq);
}
Qua area-generation, it is set up as a viewport/reference area pair,
where the viewport is the same Viewport type used for the images and
the reference-area is an InlineBlockParent.
Currently, I still sort of hacked the structure together:
* the reference-area has a single Block child that is used to add the
childAreas to
* at the end of the addAreas() loop, the viewport's content is set to
the reference-area
Maybe it would be slightly better to allow InlineBlockParent to have
multiple children, but for now, inserting that dummy Block seemed the
least intrusive way of reaching the goal.
Anyways, a small addition to cater for rendering an InlineBlockParent
in AbstractRenderer.renderViewport() did the rest.
One of the obstacles I'm running into now, and I'm hoping someone
might be able to provide pointers for, is adjusting the line-height.
See the attachment, where the inner blocks already appear nicely in
position, but the following line still overlaps. :(
It's not ready for a commit yet, but I do hope to get it in a more
usable state soon, so we can finally claim support for the XSL-FO
equivalent of HTML's IFRAME.
Cheers
Andreas
Re: Dramatic improvement of PDF text painting quality for SVG
Jeremias Maerki: As you may have see, I've reimplemented the PDFTextPainter which is part of the PDFTranscoder. All most all text is now painted using PDF text painting primitives (except for SVG fonts and where filters are used). By the way, is the FOP code after this commit still able to be compiled with Java 1.3? I would like this change to be in the final Batik 1.7 release (whenever that happens, maybe in a few weeks). -- Cameron McCormack, http://mcc.id.au/ xmpp:[EMAIL PROTECTED] ▪ ICQ 26955922 ▪ MSN [EMAIL PROTECTED]
Re: Dramatic improvement of PDF text painting quality for SVG
Not anymore. But remember that in order to include FOP's transcoders in Batik, a release needs to be made, which means a branch, which means an opportunity to temporarily work around these things. BTW, the EPS transcoder is currently broken. Everything is upside down and I haven't investigated, yet. Don't know where and when it got broken. This all just reminds me that we need to get this stuff out of FOP. I'm still on the image package redesign and will have to do a few smaller things afterwards. But after that I want to get this done. Jeremias Maerki On 06.11.2007 00:43:34 Cameron McCormack wrote: Jeremias Maerki: As you may have see, I've reimplemented the PDFTextPainter which is part of the PDFTranscoder. All most all text is now painted using PDF text painting primitives (except for SVG fonts and where filters are used). By the way, is the FOP code after this commit still able to be compiled with Java 1.3? I would like this change to be in the final Batik 1.7 release (whenever that happens, maybe in a few weeks). -- Cameron McCormack, http://mcc.id.au/ xmpp:[EMAIL PROTECTED] ▪ ICQ 26955922 ▪ MSN [EMAIL PROTECTED]
