headers
Andreas L Delmelle | 1 Apr 2007 20:44
Picon

Re: svn commit: r524603 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/Block.java

On Apr 1, 2007, at 16:49, jbryant <at> apache.org wrote:

Hi Jay,

> Author: jbryant
> Date: Sun Apr  1 07:49:12 2007
> New Revision: 524603
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=524603
> Log:
> changes to support named destination
>
> Modified:
>     xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/Block.java

Haven't tried it out yet, but a small question based solely on the  
commit-mails:
Was it sufficient to make this change to Block.java only? It's just  
that I'd expect it to be necessary on a lot of other FOs as well...

I'm also wondering if it would be necessary/worthwhile to consider  
moving the handling of extension-related logic to FOTreeBuilder. In  
that way, we could skip the validation check (or add custom  
validation logic for extensions at a more central point than  
scattered across the FOs)?

Cheers,

Andreas
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Vinkenoog | 1 Apr 2007 23:51
Picon
Gravatar

Re: svn commit: r524600 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/area/AreaTreeHandler.java

Hello Jay,

> +import org.apache.fop.area.DestinationData;

Did you forget to add DestinationData.java, or is it coming later?

Sorry if I sound impatient - I'm just interested :-)

Kind regards,
Paul Vinkenoog
Permalink | Reply | 0 comments |
headers
bugzilla | 2 Apr 2007 08:08
Picon
Favicon

Bug report for Fop [2007/04/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                                      |
|     |   |   |          |                                                  |
| 1063|New|Nor|2001-03-21|fop does not handle large fo files                |
| 1180|New|Maj|2001-04-02|Problem with monospaced font                      |
| 1773|Opn|Blk|2001-05-16|A table that is bigger than the page produces an e|
| 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                            |
| 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S|
| 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG               |
| 4767|New|Nor|2001-11-09|SVG text is distored in PDF output                |
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vincent Hennebert | 2 Apr 2007 09:38
Favicon

Re: Footnotes in the float branch

Hi,

Thinking more about it, it appears that it is not so trivial ;-).
Lacking of time to do a proper implementation, I decided to write down
my ideas on a wiki page [1]. It's not complete yet, I'll try to add
thoughts later on.

In short, I agree with you that only playing with demerits actually is
not enough like I first thought. And also that we should be as few
restrictive as possible when discarding layouts, because we will always
find problematic documents for which there is not many solutions.

Cheers,
Vincent

[1] http://wiki.apache.org/xmlgraphics-fop/FootnotesAndBeforeFloats

Luca Furini a écrit :
> Vincent Hennebert wrote:
> 
>> Hi Luca,
> 
> Hi!
> 
>> I had a look at your patch and have several comments:
>> - I see you re-enabled the noBreakBetween method; I don't think it's
>>   a good solution because it artificially prevents some nodes to be
>>   created, which even if bad may be necessary for some complex
>>   documents. See for example the attached fo file.
>
(Continue reading)

Permalink | Reply | 501 comments |
headers
Vincent Hennebert | 2 Apr 2007 10:26
Favicon

Re: Suggestion: refactoring property access in the FO tree?

Hi Andreas,

Andreas L Delmelle a écrit :
> On Mar 30, 2007, at 11:21, Vincent Hennebert wrote:
<snip/>
>>> In ancient times, each FO had a full PropertyList, so the properties
>>> could be queried via a generic get(PROPERTY_ID) accessor that was simply
>>> a proxy to the PropertyList's corresponding get(). This was, however, a
>>> much less efficient approach than what we currently have.
>>
>> To be sure I understand: each object had the very same list of
>> properties, with null values for the properties wich were not applicable
>> to it?
> 
> Errm... yes, if what you mean by 'the very same' is 'a different
> instance of the very same type'.

Yes that's what I meant. Am I imprecise sometimes. And I dare
complaining about the Rec's uncertainties ;-)

> Each FObj instance had its very own instance of the same PropertyList type.
> 
>> And the loss of efficiency was due to the indirection caused by
>> the generic get(PROPERTY_ID) I guess?
> 
> The biggest inefficiency was the space that these lists consume. They
> allocate space for an array with a number of elements equal to the
> number of /possible/ properties, effectively wasting space in case of
> FOs to which only a handful properties apply. On top of that, this space
> was not reclaimed until very late in the process, whereas now, the
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pascal Sancho | 2 Apr 2007 10:58
Picon
Favicon

RE: svn commit: r524608 - /xmlgraphics/fop/trunk/src/java/META-INF/services/org.apache.fop.fo.ElementMapping

Hi,

I get 11 errors and cannot build this rev.

Latest working rev was 524578 (for me).

I attached the build log.

Pascal

> -----Message d'origine-----
> De : jbryant <at> apache.org [mailto:jbryant <at> apache.org] 
> Envoyé : dimanche 1 avril 2007 16:51
> À : fop-commits <at> xmlgraphics.apache.org
> 
> Author: jbryant
> Date: Sun Apr  1 07:51:19 2007
> New Revision: 524608
> 
> URL: http://svn.apache.org/viewvc?view=rev&rev=524608

> Log:
> changes to support named destinations
> 
> Modified:
>     
> xmlgraphics/fop/trunk/src/java/META-INF/services/org.apache.fo
> p.fo.ElementMapping
> 
> Modified: 
> xmlgraphics/fop/trunk/src/java/META-INF/services/org.apache.fo
(Continue reading)

Permalink | Reply | 501 comments |
headers
Paul Vinkenoog | 2 Apr 2007 11:03
Picon
Gravatar

RE: svn commit: r524608 - /xmlgraphics/fop/trunk/src/java/META-INF/services/org.apache.fop.fo.ElementMapping

Hi Pascal,

> I get 11 errors and cannot build this rev.
>
> Latest working rev was 524578 (for me).

It's because DestinationData.java is missing.

Regz,
Paul Vinkenoog
Permalink | Reply | 501 comments |
headers
Adrian Cumiskey | 2 Apr 2007 11:05
Picon

startPageSequence() in Renderer interface

Hi,

I am working on the postscript renderer and have a query about 
org.apache.fop.render.Renderer#void startPageSequence(LineArea title). 
Its seems a bit wrong to me that this method is invoked with just the 
title of the PageSequence being passed to it, surely it would be better 
to pass the PageSequence itself (which contains the title).  I would 
think that the PageSequence object itself would be much more useful to 
the renderer.  Am I missing something?  Is there a good reason which I 
have missed as to why it is implemented in this way?

Adrian Cumiskey.
Permalink | Reply | 5 comments |
headers
bugzilla | 2 Apr 2007 11:40
Picon
Favicon

DO NOT REPLY [Bug 41831] - [PATCH] Refactored configuration, font detection and caching, url resolution

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

------- Additional Comments From dev <at> cumiskey.com  2007-04-02 02:40 -------
Hi Keith,

Many thanks for trying out the patch and taking the time to provide me with
feedback.  My comments are below.

(In reply to comment #17)
> I tried out this patch on Ubuntu Linux and found that I needed a few changes to
> get it to work properly. Since this hasn't been checked in, I'm not sure what to
> send a patch against, so I'll just describe them for now.
> 
> org.apache.fop.fonts.autodetect.UnixFontDirFinder
> It is probably worth adding the .fonts directory in a user's home directory: e.g.
> 
> UNIX_FONT_PATHS = {
>         System.getProperty("user.home") + "/.fonts",

Ok this is a nice easy addition.  Andreas, if you are reading this
I believe you have made some small changes.  Before I make any of the changes
that Keith suggests, it might be a good idea for you to attach an additional
patch file with your changes.
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla | 2 Apr 2007 15:37
Picon
Favicon

DO NOT REPLY [Bug 41831] - [PATCH] Refactored configuration, font detection and caching, url resolution

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

------- Additional Comments From dev <at> cumiskey.com  2007-04-02 06:37 -------
Created an attachment (id=19890)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19890&action=view)
updated files from org.apache.fop.fonts.autodetect package

Following feedback from Andreas and Keith I have updated the autodetect
package.  I hope this does not cause you too many merge problems Andreas.

--

-- 
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 |

Gmane