headers
bugzilla | 1 Jan 2006 13:42
Picon
Favicon

DO NOT REPLY [Bug 38087] New: - [patch] force-page-count property implementation

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=38087>.
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=38087

           Summary: [patch] force-page-count property implementation
           Product: Fop
           Version: 1.0dev
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: page-master/layout
        AssignedTo: fop-dev <at> xmlgraphics.apache.org
        ReportedBy: gerhard.oettl <at> oesoft.at

This patch (re)implements the force-page-count property.

I tried to implement it with as little changes to the
code as possible. Therefore some design issues and questions
remain - see later.

Description:
The force-page-count property is handled by adding a method
to the PageSequenceLayoutManger, because there are is a
method that has all informations (static content, pagenumber,
(Continue reading)

Permalink | Reply | 19 comments |
headers
bugzilla | 1 Jan 2006 13:44
Picon
Favicon

DO NOT REPLY [Bug 38087] - [patch] force-page-count property implementation

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=38087>.
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=38087

------- Additional Comments From gerhard.oettl <at> oesoft.at  2006-01-01 13:44 -------
Created an attachment (id=17303)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17303&action=view)
the patch itself

--

-- 
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.
Permalink | Reply | 0 comments |
headers
bugzilla | 1 Jan 2006 13:45
Picon
Favicon

DO NOT REPLY [Bug 38087] - [patch] force-page-count property implementation

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=38087>.
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=38087

------- Additional Comments From gerhard.oettl <at> oesoft.at  2006-01-01 13:45 -------
Created an attachment (id=17304)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17304&action=view)
this fo i used for testing (no automated test case)

--

-- 
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.
Permalink | Reply | 0 comments |
headers
Andreas L Delmelle | 1 Jan 2006 14:29
Picon

Re: DO NOT REPLY [Bug 38087] New: - [patch] force-page-count property implementation

On Jan 1, 2006, at 13:42, bugzilla <at> apache.org wrote:

Hi Gerhard,

>
>            Summary: [patch] force-page-count property implementation
>            Product: Fop
>
>
> This patch (re)implements the force-page-count property.

What better way to start the new year than by extending FOP's  
functionality, ay? :-)

Thanks for offering this patch. All in all, it looks good AFAICT at  
first glance.

> I know the force-page-count property is of low priority, but
> it would be nice to get feedback, if someone can spare time
> to have a look at this patch.

Don't worry about priorities. Every little bit helps. Things that are  
low-priority are most likely to be features that other devs currently  
don't have the time to look at. If guys like you do have the time and  
the ideas, all the better.

We'll have a closer look ASAP. Stay tuned.

>
> happy new year
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andreas L Delmelle | 1 Jan 2006 15:22
Picon

Re: svn commit: r360083 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/flow/ test/layoutengine/standard-testcases/

On Dec 31, 2005, at 17:02, Andreas L Delmelle wrote:

(been pondering a bit more over this, and...)

> Et voilà, that seems to be where the real *flaw* is located, if you  
> ask me. It should care about glues at the beginning of a line -- 
> which it seems to handle perfectly ATM--

In fact, this may currently be handled 'too perfectly'. One of the  
testcases --block_white-space_2.xml-- fails because a leading non- 
breaking space is removed, contrary to the expectation.

Don't get me wrong. I still think that it is unnecessary to remove  
the mentioned trailing white-space for trailing nested inlines in a  
paragraph in the FOTree.

Only, I think I'm beginning to see what is meant by this paradox:

> Besides that, I get the impression you're somewhat contradicting  
> yourself here:
> - in the comment on the failing testcase you noted that 'These  
> tests fail because the Knuth element sequences for consecutive  
> whitespace are not correct.'
> - and now you're saying that it's not a matter of generating the  
> correct element sequences

The flaw here is that, IIC, the element sequences generated for nbsp  
are basically the same as for a common space, leading to the exact  
same type of area being (or not being) added to the Area Tree (=  
<space .../>)
(Continue reading)

Permalink | Reply | 15 comments |
headers
Manuel Mall | 1 Jan 2006 17:04
Picon

Re: svn commit: r360083 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/flow/ test/layoutengine/standard-testcases/

On Sun, 1 Jan 2006 12:02 am, Andreas L Delmelle wrote:
> On Dec 31, 2005, at 16:05, Manuel Mall wrote:
>
> The possible problem I saw with the block-level white-space handling
> was that all white-space characters would continue to take up memory
> until the first nested block or in the worst case, until the end-of-
> block. In case of large blocks with lots of indents due to pretty-
> printing, the current approach makes these spaces disappear much
> sooner (= more memory-efficient).
>
Andreas,

you can't be serious here. Keeping a few whitespace characters until the 
end of a block is reached is completely irrelevant with respect to FOPs 
memory consumption and should not play even the slightest consideration 
when comes to choice of algorithm. If this is the only reason which 
stops you from doing end of paragraph line-feed-treatment during 
refinement then please revise the algorithm to do so.

<snip/>
>
> Cheers,
>
> Andreas

Manuel
Permalink | Reply | 0 comments |
headers
Manuel Mall | 1 Jan 2006 17:15
Picon

Re: svn commit: r360083 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/flow/ test/layoutengine/standard-testcases/

On Sun, 1 Jan 2006 10:22 pm, Andreas L Delmelle wrote:
> On Dec 31, 2005, at 17:02, Andreas L Delmelle wrote:
>
> (been pondering a bit more over this, and...)
>
> > Et voilà, that seems to be where the real *flaw* is located, if you
> > ask me. It should care about glues at the beginning of a line --
> > which it seems to handle perfectly ATM--
>
> In fact, this may currently be handled 'too perfectly'. One of the
> testcases --block_white-space_2.xml-- fails because a leading non-
> breaking space is removed, contrary to the expectation.
>
> Don't get me wrong. I still think that it is unnecessary to remove
> the mentioned trailing white-space for trailing nested inlines in a
> paragraph in the FOTree.
>
> Only, I think I'm beginning to see what is meant by this paradox:
> > Besides that, I get the impression you're somewhat contradicting
> > yourself here:
> > - in the comment on the failing testcase you noted that 'These
> > tests fail because the Knuth element sequences for consecutive
> > whitespace are not correct.'
> > - and now you're saying that it's not a matter of generating the
> > correct element sequences
>

You still don't seem to quite get my point.

The Knuth algorithm (read the paper) deals only with box/pen/glue for
(Continue reading)

Permalink | Reply | 14 comments |
headers
Andreas L Delmelle | 1 Jan 2006 17:56
Picon

Re: svn commit: r360083 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/flow/ test/layoutengine/standard-testcases/

On Jan 1, 2006, at 17:15, Manuel Mall wrote:

> The Knuth algorithm (read the paper) deals only with box/pen/glue for
> the purpose of breaking lines and if it breaks a line it takes certain
> actions with respect to discarding pen/glue elements directly  
> following
> the break it created. If it doesn't create a line break it leaves
> everything as it is. This means everything at the beginning and end of
> a paragraph is left untouched. line-feed-treatment at the beginning  
> and
> end of a paragraph is not influenced by the Knuth algorithm and
> therefore cannot be controlled by whatever sequences we generate.

Ahem... I do get your point, but the fact of the matter remains that  
the trailing spaces should be removed for the reason that they would  
end up at the end of a *line-area*, not because they end up at the  
end of the *paragraph*.

I have no trouble grasping the idea that the Knuth algorithm only  
creates effective breaks in intermediate positions, and takes certain  
actions for those breaks. Ok, so that means the start- or end-of- 
paragraph line-break is not created by this algorithm in itself, and  
remains out-of-scope here. Would it not be a much easier and much  
more straightforward solution to have every paragraph end with an  
infinitely low penalty, so that the algorithm eventually treats  
trailing spaces in the last line-area just the same as it would for  
'normal' line-breaks?

> We can control line-feed-treatment at Knuth generated breaks by
> constructing the proper sequences which we will do eventually. But
(Continue reading)

Permalink | Reply | 13 comments |
headers
bugzilla | 1 Jan 2006 23:08
Picon
Favicon

Bug report for Fop [2006/01/01]

+---------------------------------------------------------------------------+
| Bugzilla Bug ID                                                           |
|     +---------------------------------------------------------------------+
|     | Status: UNC=Unconfirmed NEW=New         ASS=Assigned                |
|     |         OPN=Reopened    VER=Verified    (Skipped Closed/Resolved)   |
|     |   +-----------------------------------------------------------------+
|     |   | Severity: BLK=Blocker     CRI=Critical    MAJ=Major             |
|     |   |           MIN=Minor       NOR=Normal      ENH=Enhancement       |
|     |   |   +-------------------------------------------------------------+
|     |   |   | Date Posted                                                 |
|     |   |   |          +--------------------------------------------------+
|     |   |   |          | Description                                      |
|     |   |   |          |                                                  |
|  635|Opn|Nor|2001-02-18|Doesn't support id= attribute in fo:page-sequence |
|  953|Opn|Nor|2001-03-12|Incorrect hyperlinks area rendering in justified t|
| 1063|New|Nor|2001-03-21|fop does not handle large fo files                |
| 1180|New|Maj|2001-04-02|Problem with monospaced font                      |
| 1859|Opn|Min|2001-05-22|org.apache.fop.apps.Driver.reset() doesn't fully r|
| 1998|New|Nor|2001-06-05|linefeed-treatment not understood                 |
| 2150|Ass|Maj|2001-06-13|New page with  a table-header but without any tabl|
| 2475|Ass|Nor|2001-07-06|Borders don't appear to work in <fo:table-row>    |
| 2740|New|Maj|2001-07-23|multi-page tables sometimes render badly          |
| 2909|New|Maj|2001-07-30|Gradient render error                             |
| 2964|Ass|Nor|2001-08-02|problems with height of cells in tables           |
| 2988|New|Maj|2001-08-03|0.19: list-item-label does not stick to list-item-|
| 3044|Ass|Maj|2001-08-08|keep-together not functioning                     |
| 3280|New|Nor|2001-08-27|PCL Renderer doesn't work                         |
| 3305|Opn|Nor|2001-08-28|list-block overlapping footnote body              |
| 3497|New|Cri|2001-09-07|id already exists error when using span="all" attr|
| 3824|New|Blk|2001-09-25|MIF option with tables                            |
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla | 1 Jan 2006 23:49
Picon
Favicon

DO NOT REPLY [Bug 38089] New: - image rendering differs between 0.90 and 0.91

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=38089>.
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=38089

           Summary: image rendering differs between 0.90 and 0.91
           Product: Fop
           Version: 0.91
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: images
        AssignedTo: fop-dev <at> xmlgraphics.apache.org
        ReportedBy: j_cumps <at> yahoo.com

While rendering a .bmp image in fop 0.90alpha1 the pdf renderer rendered the 
image with exact size, it is resized in 0.90beta.

My bitmap EventReminderIntegration.bmp has a width of 13.56cm, and a height of 
5.95cm.

My xml contains this code:

    <fo:block space-before.optimum="20pt">
      <fo:external-graphic content-width="13.56cm" content-height="5.95cm"
(Continue reading)

Permalink | Reply | 2 comments |

Gmane