DO NOT REPLY [Bug 43542] - MalformedURIException during usage of user FOP configuration...
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=43542. 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=43542 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED -- 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 43542] - MalformedURIException during usage of user FOP configuration...
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=43542. 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=43542 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2007-10-04 02:06 --- Problem fixed in FOP Trunk: http://svn.apache.org/viewvc?rev=581806view=rev -- 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 43041] - [PATCH] AFP Renderer - output resolution control
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=43041. 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=43041 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2007-10-04 06:44 --- I've got a question for those who use AFP: Adrian introduced a renderer-resolution setting. All the other renderers use target-resolution [1]. Since the AFP renderer's default resolution is 240dpi instead of 72 dpi like for the other renderers. Switching to target-resolution would decrease the output quality for those who use the AFP renderer at its default settings. But introducing renderer-resolution adds a third resolution setting which could lead to confusion. Should we perhaps let each renderer try to give the user agent its default target resolution? Opinions? Ideas? [1] http://xmlgraphics.apache.org/fop/0.94/configuration.html#general-elements -- 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 42144] - [PATCH] Safely set postscript page device dictionary
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=42144. 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=42144 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2007-10-04 06:53 --- I've done some testing with your patch Adrian and it appears to work very well. None of the previous problems reported by Jeremias showed up. I was able to print Postscript and view in GhostView with all 4 combinations of the new options that you've added. So I have committed the patch. Thanks! -- 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 43070] - [PATCH] Postscript extension : comment before and after page
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=43070. 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=43070 Bug 43070 depends on bug 42144, which changed state. Bug 42144 Summary: [PATCH] Safely set postscript page device dictionary http://issues.apache.org/bugzilla/show_bug.cgi?id=42144 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED -- 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.
Re: AFP Output Resolution
Ok, I agree that renderer-resolution is a good name if we need a per-renderer setting for the resolution. But applying Adrian's patch #43041 would leave the codebase in a strange situation where you have to configure the AFP renderer through the renderer setting and the TIFF/PNG renderers through target-resolution. And that just begs for confusion. I guess I still have a problem where to draw the line between target-resolution and renderer-resolution, for example when looking at the PDF renderer. Jeremias Maerki On 02.08.2007 15:28:23 Chris Bowditch wrote: Vincent Hennebert wrote: Hi Chris, Hmmm, I’m perhaps making a confusion here. I thought target-resolution did also apply to the whole images generated by the renderer; i.e., for the TIFF renderer, the resolution of the image representing the whole document, and not only images inside it. Isn’t that the case? Then, why wouldn’t target-resolution also apply to images in PDF output? Good point. I overlooked the Tiff and PNG Renderers in my reply. Target aka default resolution would apply to images in PDF as well as the resolution of the generated Tiff, PNG etc. Perhaps I should ask the question on fop-user, I’m sure I will find there nice developers who will enlighten me... output and target have similar semantics in the English language and the distinction between them will not be clear enough for the users. Maybe the general purpose one (which currently only controls batik) should be default-resolution and it could also apply to images for renderers which dont have an explicit renderer-resolution renderer-resolution sounds fine to me. Great. I think it is a lot clearer than output-resolution Chris
DO NOT REPLY [Bug 43070] - [PATCH] Postscript extension : comment before and after page
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=43070. 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=43070 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED -- 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.
Re: AFP Output Resolution
On 04.10.2007 16:39:05 Chris Bowditch wrote: Jeremias Maerki wrote: Ok, I agree that renderer-resolution is a good name if we need a per-renderer setting for the resolution. But applying Adrian's patch #43041 would leave the codebase in a strange situation where you have to configure the AFP renderer through the renderer setting and the TIFF/PNG renderers through target-resolution. And that just begs for confusion. I guess I still have a problem where to draw the line between target-resolution and renderer-resolution, for example when looking at the PDF renderer. Well if the renderer-resolution is specified for PDF then it overrides the target-resolution. Otherwise the PDF renderer should use target-resolution as it does now. Yes, that works for PDF, but for AFP, the default resolution is 240 dpi. Not specifying a renderer-resolution would make the default resolution 72 dpi from the target-resolution. I guess I'll just add a check to see if the target-resolution is on the default value in which case AFP would still use 240 dpi. I think a per renderer resolution is needed because users are likely to want to treat AFP differently to Tiff output. I don't think it is acceptable to require a separate configuration file depending on whether you want to generate AFP or Tiff etc. I can agree with that. Thanks a lot, Jeremias Maerki
Re: AFP Output Resolution
Jeremias Maerki wrote: Ok, I agree that renderer-resolution is a good name if we need a per-renderer setting for the resolution. But applying Adrian's patch #43041 would leave the codebase in a strange situation where you have to configure the AFP renderer through the renderer setting and the TIFF/PNG renderers through target-resolution. And that just begs for confusion. I guess I still have a problem where to draw the line between target-resolution and renderer-resolution, for example when looking at the PDF renderer. Well if the renderer-resolution is specified for PDF then it overrides the target-resolution. Otherwise the PDF renderer should use target-resolution as it does now. I think a per renderer resolution is needed because users are likely to want to treat AFP differently to Tiff output. I don't think it is acceptable to require a separate configuration file depending on whether you want to generate AFP or Tiff etc. snip/ Chris
Interleaved line-/page-breaking: list-blocks working?
Hi
Just played a bit more with Simon's (cool!) branch, and tried
overriding ListItemContentLM.getNextKnuthElements() to the following:
public LinkedList getNextKnuthElements(LayoutContext context,
int alignment) {
LinkedList baseList = super.getNextKnuthElements(context,
alignment);
ListElement el;
LinkedList resultList = new LinkedList();
LinkedList tmpList;
for (Iterator i = baseList.iterator(); i.hasNext();) {
el = (ListElement) i.next();
if (el instanceof ParagraphListElement) {
tmpList = ((ParagraphListElement) el).doLineBreaking();
resultList.addAll(tmpList);
} else {
resultList.add(el);
}
}
return resultList;
}
I am unsure as to whether this is 'in the spirit of the algorithm' so
to speak, but the result is that all list-related tests now pass.
End-result: 246 out of 368 tests pass on my end.
If anyone can confirm that this is a good way to go about it, I'll
commit it to the branch shortly, and start looking at getting tables
to work as well.
Cheers
Andreas
Re: Interleaved line-/page-breaking: list-blocks working?
Your change tries to undo my change as soon as possible. In trunk the
paragraphs were broken into lines by the LineLM. Now that happens by
the ListItemContentLM, which is only a little bit higher up.
It still leaves it impossible to break a list item over a page, and
let the next page have a different IPD. For that to be possible, the
list item must be broken into lines as late as possible, when the page
breaker needs them for a specific page.
Simon
On Thu, Oct 04, 2007 at 07:32:19PM +0200, Andreas L Delmelle wrote:
Hi
Just played a bit more with Simon's (cool!) branch, and tried overriding
ListItemContentLM.getNextKnuthElements() to the following:
public LinkedList getNextKnuthElements(LayoutContext context, int
alignment) {
LinkedList baseList = super.getNextKnuthElements(context,
alignment);
ListElement el;
LinkedList resultList = new LinkedList();
LinkedList tmpList;
for (Iterator i = baseList.iterator(); i.hasNext();) {
el = (ListElement) i.next();
if (el instanceof ParagraphListElement) {
tmpList = ((ParagraphListElement) el).doLineBreaking();
resultList.addAll(tmpList);
} else {
resultList.add(el);
}
}
return resultList;
}
I am unsure as to whether this is 'in the spirit of the algorithm' so to
speak, but the result is that all list-related tests now pass.
End-result: 246 out of 368 tests pass on my end.
--
Simon Pepping
home page: http://www.leverkruid.eu
Re: Temp_Interleaved_Page_Line_Breaking
That is a rather ideal situation. It requires not only interleaving of
page and line breaking, but also of page breaking and collection of
Knuth elements. That requires some communication. The collection of
Knuth elements is deeply recursive, LM.getNextKnuthElements. Each LM
now needs to pass its Knuth elements to the page breaker or the lowest
line breaker in the hierarchy. That can be accommodated by passing
that receiving object as an argument in
LM.getNextKnuthElements. Especially for the LMs in block mode (block
LMs and line LMs) it is important that they communicate their elements
soon, to allow the page breaker to interrupt the process and proceed
with the breaking calculations. In restricted block mode and inline
mode, i.e. mainly InlineLMs, that is not important, because the LineLM
will complete each paragraph before communicating it up.
This change is only meaningful for a best-fit strategy for one or a
few pages. For the total-fit strategy it adds complexity but no memory
efficiency. That is because this strategy cannot take a decision until
the whole page sequence is processed.
Simon
On Tue, Oct 02, 2007 at 11:31:12PM +0200, Andreas L Delmelle wrote:
Just thought of it this way:
Instead of collecting all the ListElements for the whole page-sequence in
one massive recursive iteration as is the case now
(getNextKnuthElements()), maybe the algorithm can be 'slightly' altered in
such a way that the FlowLM repeatedly checks back with the PageSequenceLM
and updates the LayoutContext for the active page.
Not: collect *all* lines/paragraphs first, and only then *all* pages (may
be total-fit, I'm not sure I would call it that...).
But rather, an incremental total-fit:
while (moreContent) {
collect more lines
if (accumulated line-height causes an implicit but unavoidable
page-break) {
run page-breaking algorithm over the accumulated lines
}
}
Obviously, the if-test is only a very rough estimation, but a good one,
since it guarantees that the sequence always generates at least one
page-break (no space-resolution, footnotes, floats taken into account here
yet)
That would provide our 'interference' point, where decisions can be made
about whether to continue accumulating layout-possibilities or interrupt,
start adding areas based upon the best possibility so far, and resume, but
with a cleared state. The head of the list of lines/pages will be chopped
off, and their possibilities need no longer be considered.
If I interpret correctly, the node corresponding to the 'best' overall
break for the first line/page (the one chosen by a total-fit
implementation), in many cases can be determined quite early in the
process. You don't always need to look at all words/lines in the
paragraph/page-sequence for that.
--
Simon Pepping
home page: http://www.leverkruid.eu
