headers
Andreas Delmelle | 1 Jul 2008 20:57
Picon
Favicon

Re: Include XSL-FO 1.1 features


On Jun 19, 2008, at 20:05, Andreas Delmelle wrote:

> On Jun 19, 2008, at 18:34, Jean-François El Fouly wrote:

Jean-François (and other interested parties),

Just as a heads-up:

>> <snip />
>> Before going any further, will 1.1 features be considered by the  
>> dev team
>> for inclusion in FOP trunk if ever we succeed in implementing them ?
>
> Definitely! In current FOP trunk, fo:retrieve-table-marker has been  
> prepared to some extent (the FO-tree side is roughly OK)
>
> For the remainder, I can think of a few other features I was  
> recently thinking of myself:
> - fo:folio-prefix / fo:folio-suffix (this I think to be the most  
> straightforward to implement)

During the weekend, I already committed a change to Constants.java as  
a very small first step.

In the meantime, I'm close to getting fo:folio-prefix and fo:folio- 
suffix to work.

The rest remains open for now. Just thought I'd let this know, so we  
don't work on the same things.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luca Furini | 2 Jul 2008 10:03
Picon

Re: Absolute-positioned block-containers using left and bottom

(I'm re-posting this message as I sent it yesterday and still cannot see 
it in the list archives, I hope I'm not duplicating it unnecessarily)

On Mon, Jun 23, 2008 at 5:12 PM, Luca Furini <lfurini <at> cs.unibo.it> wrote:

> If there is a block-container with both width and height set, its
> position can be correctly controlled using top and left (and indeed
> there are many testcases checking that) but bottom and right do not
> have any visible effect.

I've solved the bug for simple situations, but the solution is not
nearly general enough to be committed.

The point is: right and bottom distances need to be respectively
translated into x- and y-offset at some time, and in doing this we
must know the ipd and bpd of the nearest ancestor reference area, as,
for example,
   x-offset = reference-bpd - object-bpd - right-distance

My first idea was to set the offsets at the LM level, when creating
areas, so that there would be no changes at all for the renderers, but
I failed to find a way to obtain the nearest ancestor reference area,
as areas have no parent pointer (and I couldn't even think of a nice
way to find the appropriate region reference ...).

So, I'm almost convinced that the bottom- and right- distances should
be preserved in the area tree, and translated into offset during the
rendering, where it would be possible to keep updated a
nearestReferenceArea pointer just like current*PPosition is.
(Continue reading)

Permalink | Reply | 503 comments |
headers
Andreas Delmelle | 2 Jul 2008 20:24
Picon
Favicon

Re: Absolute-positioned block-containers using left and bottom

On Jul 2, 2008, at 10:03, Luca Furini wrote:

Hi Luca

> On Mon, Jun 23, 2008 at 5:12 PM, Luca Furini <lfurini <at> cs.unibo.it>  
> wrote:
>
>> If there is a block-container with both width and height set, its
>> position can be correctly controlled using top and left (and indeed
>> there are many testcases checking that) but bottom and right do not
>> have any visible effect.
>
> I've solved the bug for simple situations, but the solution is not
> nearly general enough to be committed.
>
> The point is: right and bottom distances need to be respectively
> translated into x- and y-offset at some time, and in doing this we
> must know the ipd and bpd of the nearest ancestor reference area, as,
> for example,
>   x-offset = reference-bpd - object-bpd - right-distance
>
> My first idea was to set the offsets at the LM level, when creating
> areas, so that there would be no changes at all for the renderers, but
> I failed to find a way to obtain the nearest ancestor reference area,
> as areas have no parent pointer (and I couldn't even think of a nice
> way to find the appropriate region reference ...).

I'm beginning to wonder...
If you have the area's own dimensions, and the complement properties  
(bottom-right), is that not enough?
(Continue reading)

Permalink | Reply | 503 comments |
headers
The Web Maestro | 3 Jul 2008 00:05
Picon
Gravatar

PDF format becomes ISO standard (ISO 32000-1)

Greetings FOP Folks,

I thought I'd let you know (in case you didn't already 'hear') that
the ISO has a new standard[1]:

  ISO 32000-1, Document management – Portable document format – Part 1: PDF 1.7

Here're some choice pieces from the article...

The Portable Document Format (PDF), undeniably one of the most
commonly used formats for electronic documents, is now accessible as
an ISO International Standard - ISO 32000-1. This move follows a
decision by Adobe Systems Incorporated, original developer and
copyright owner of the format, to relinquish control to ISO, who is
now in charge of publishing the specifications for the current version
(1.7) and for updating and developing future versions.

"By releasing the full PDF specification for ISO standardization, we
are reinforcing our commitment to openness", says Kevin Lynch, Chief
Technology Officer at Adobe. "As governments and organizations
increasingly request open formats, maintenance of the PDF
specification by an external and participatory organization will help
continue to drive innovation and expand the rich PDF ecosystem that
has evolved over the past 15 years."

...

The new standard, ISO 32000-1, Document management – Portable document
format – Part 1: PDF 1.7, is based on the PDF version 1.7 developed by
Adobe. This International Standard supplies the essential information
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luca Furini | 3 Jul 2008 14:45
Picon

Absolute-positioned block-containers using left and bottom

(it's still me, I just subscribed with the gmail account I use more
frequently, to avoid problems of messages not reaching the list ...)

On Wed, Jul 2, 2008 at 8:24 PM, Andreas Delmelle
<andreas.delmelle <at> telenet.be> wrote:

> If you have the area's own dimensions, and the complement properties
> (bottom-right), is that not enough?
>
> For the renderer:
> -> top = (bottom - area-bpd - borders - padding))
> -> left = (right - area-bpd - borders - padding))

Bottom is the distance from the nearest ancestor reference area
*bottom* edge, not from the top one (the same for left), so we need to
know the reference bpd and ipd.
If I read the spec right, a 10pt bottom position set on the same
absolutely positioned block-container would be translated into
different top-positions according to the the reference bpd (= the
reference bottom edge).

> It seems so simple... Am I missing something?

*At least* one of us is missing something ;-)

> (It's hot here, too! ;-))

We probably need a summer team located in the southern hemisphere!

Regards
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luca Furini | 3 Jul 2008 12:33
Picon

Re: Absolute-positioned block-containers using left and bottom

On Wed, Jul 2, 2008 at 8:24 PM, Andreas Delmelle
<andreas.delmelle <at> telenet.be> wrote:

> If you have the area's own dimensions, and the complement properties
> (bottom-right), is that not enough?
>
> For the renderer:
> -> top = (bottom - area-bpd - borders - padding))
> -> left = (right - area-bpd - borders - padding))

Bottom is the distance from the nearest ancestor reference area
*bottom* edge, not from the top one (the same for left), so we need to
know the reference bpd and ipd.
So, if I read the spec right, a 10pt bottom position set on the same
absolutely positioned block-c would translated into different
top-positions according to the the reference bpd (= the reference
bottom edge).

> It seems so simple... Am I missing something?

*At least* one of us is missing something ;-)

> (It's hot here, too! ;-))

We probably need a summer team located in the southern hemisphere!

Regards
   Luca
(Continue reading)

Permalink | Reply | 4 comments |
headers
bugzilla | 4 Jul 2008 14:20
Picon
Favicon

DO NOT REPLY [Bug 45342] New: AFP Renderer does not properly handle AFP fonts with relative metric

https://issues.apache.org/bugzilla/show_bug.cgi?id=45342

           Summary: AFP Renderer does not properly handle AFP fonts with
                    relative metric
           Product: Fop
           Version: 0.94
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: general
        AssignedTo: fop-dev <at> xmlgraphics.apache.org
        ReportedBy: styryx <at> seznam.cz

Created an attachment (id=22215)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22215)
changed AFPFontReader.java

I've tried to use AFP renderer along with AFP fonts with relative metrics,
which results in wrong alignment of text. For both Outline fonts (scalable) and
Raster fonts.

After some debugging I've updated the
org.apache.fop.render.afp.fonts.AFPFontReader.java file to process these fonts
correctly, I attach the updated Java file below. (the main problem is, that AFP
fonts have two measurement unit setting, which should be both considered for
fonts with relative metric - metric resolution and shape resolution; and the
factor to be applied to measurement values depends on the pointsize in some
cases)
(Continue reading)

Permalink | Reply | 5 comments |
headers
Andreas Delmelle | 4 Jul 2008 18:09
Picon
Favicon

Re: Absolute-positioned block-containers using left and bottom

On Jul 3, 2008, at 12:33, Luca Furini wrote:

Hi Luca

> On Wed, Jul 2, 2008 at 8:24 PM, Andreas Delmelle
> <andreas.delmelle <at> telenet.be> wrote:
>
>> If you have the area's own dimensions, and the complement properties
>> (bottom-right), is that not enough?
>>
>> For the renderer:
>> -> top = (bottom - area-bpd - borders - padding))
>> -> left = (right - area-bpd - borders - padding))
>
> Bottom is the distance from the nearest ancestor reference area
> *bottom* edge, not from the top one (the same for left), so we need to
> know the reference bpd and ipd.

Right! /That/ was what I was missing...

> So, if I read the spec right, a 10pt bottom position set on the same
> absolutely positioned block-c would translated into different
> top-positions according to the the reference bpd (= the reference
> bottom edge).

Yes, I concur, you need the reference-area bpd to compute 'bottom',  
also when deriving 'top' from that.

Now, I'm wondering... In theory, it should not be too difficult to  
get at this info, since ultimately it is also needed when computing
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andreas Delmelle | 6 Jul 2008 10:03
Picon
Favicon

Re: svn commit: r674267 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/area/AreaTreeParser.java

On Jul 6, 2008, at 09:50, adelmelle <at> apache.org wrote:

> Author: adelmelle
> Date: Sun Jul  6 00:50:23 2008
> New Revision: 674267
>
> URL: http://svn.apache.org/viewvc?rev=674267&view=rev
> Log:
> Switch AreaTreeParser to use a java.nio.CharBuffer, and ignore  
> characters events for all elements other than <word>, <space> or  
> <character>

Just FYI: this should fix the issue that was reported about a month  
ago on fop-users <at>  by Martin Edge. If the intermediate area tree was  
indented, the AreaTreeParser would make errors when collecting the  
characters.

The solution was pretty straightforward, since the area tree cannot  
contain mixed objects (having both text and child elements). I  
suppose we're going to keep it that way. If not, then we may have to  
revisit this...

Cheers

Andreas
Permalink | Reply | 0 comments |
headers
Adrian Cumiskey | 6 Jul 2008 10:37
Picon

Re: svn commit: r674269 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: area/AreaTreeParser.java area/inline/Character.java render/AbstractRenderer.java

Hi Andreas,

This commit looks to undo some changes I made to AbstractRenderer in 
r674056.  Was wondering if this was intentional?

r674056 took the null port variable test out of renderRegionViewPort() 
so there would be one less method call in the case when there is no 
RegionViewport and also simplified some of the Trait boolean tests.

Adrian.

adelmelle <at> apache.org wrote:
> Author: adelmelle
> Date: Sun Jul  6 01:15:50 2008
> New Revision: 674269
> 
> URL: http://svn.apache.org/viewvc?rev=674269&view=rev
> Log:
> Remove deprecated Character area class
> 
> Removed:
>     xmlgraphics/fop/trunk/src/java/org/apache/fop/area/inline/Character.java
> Modified:
>     xmlgraphics/fop/trunk/src/java/org/apache/fop/area/AreaTreeParser.java
>     xmlgraphics/fop/trunk/src/java/org/apache/fop/render/AbstractRenderer.java
> 
> Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/area/AreaTreeParser.java
> URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/area/AreaTreeParser.java?rev=674269&r1=674268&r2=674269&view=diff
> ==============================================================================
> --- xmlgraphics/fop/trunk/src/java/org/apache/fop/area/AreaTreeParser.java (original)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane