Re: Collapsing borders: FOTree stage -- progress update

[Manuel Mall]

On Sat, 27 Aug 2005 02:07 am, Andreas L Delmelle wrote:
> Hi all,
>

> * The first step I took was moving much of the logic that is
> currently in CollapsingBorderModelEyeCatching (in the layout package)
> to CommonBorderPaddingBackground.

I must admit I know very little about collapsing borders. Therefore if 
my comment is useless just ignore it.

I have recently worked on all this "percentage" stuff. This applies also 
to border-width specifications. I believe border-width is one of the 
inputs to the border collapse algorithm. Relative border-width 
specifications can only be resolved at layout time (with the 
appropriate context). This seems to indicate the border collapse 
algorithm (at least the parts related to border-width) can only run 
during layout.


> Cheers,
>
> Andreas

Manuel

Re: Collapsing borders: FOTree stage -- progress update

[Jeremias Maerki]

On 27.08.2005 23:19:40 Andreas L Delmelle wrote:

> BTW: since it is my intention to facilitate the job of the layout 
> package in this matter, I'm considering adding BorderInfo instances 
> (although I'm not sure where exactly) that keep the resolved info to 
> use precisely in these layout-specific cases. What I mean is: even if 
> the FOTree lacks some of the context, there is always the fact that it 
> is a possibility (however remote) to have a page-break between two body 
> elements.
> We could say: the BorderInfo to use in 95% of the cases is the one that 
> is immediately available in the element's CommonBorderPaddingBackground 
> instance, in the other 5% it's another one, available 'over there' 
> (wherever that is). Layout would then not need to re-evaluate, but pick 
> up the width from that 'special' BorderInfo instance.
> Does this sound like a sane thing?

Remembering your earlier ideas for your approach, I think so, although I
must say that I'm not sure if I really understand it. I keep having
problems following your ideas sometimes, but that's mostly because I'm
not so much the theoretical guy. AFAIK you're trying to move the
pre-resolvable pieces into the FO tree while you only do the
specialities in the LMs, right?


Jeremias Maerki

DO NOT REPLY [Bug 36391] - [PATCH] reference-orientation and negative values

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=36391


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-08-27 23:57 ---
Patch applied. Thanks a lot, especially for the test case.
http://svn.apache.org/viewcvs?rev=240459&view=rev
http://svn.apache.org/viewcvs?rev=240461&view=rev

The result for 180 and -180 is definitely wrong. There's a bug that needs to be
fixed eventually. But since this is low-priority for me, I'm going to leave it
for now. I've added a comment to the new test case block-container4a that
explains what is wrong. So I think I'll close this issue. It's primarily for the
patch, after all, and the bug won't be missed now that there is a check in our
test suite. If anyone disagrees, just reopen the issue or create a new one.

-- 
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: Collapsing borders: FOTree stage -- progress update

[Andreas L Delmelle]

On Aug 27, 2005, at 22:22, Jeremias Maerki wrote:



On 27.08.2005 21:33:44 Andreas L Delmelle wrote:


I'm wondering, for instance, whether the table's before-border specs
are only relevant for the first page that is spanned by the table. For
example: in case the table has a header (and
omit-header-at-break="false"), and the table's before-border wins, 
then

it can still *appear* on the following pages (but that will be because
it *is* the header's before-border).


No, the table only has an own border in the separate border model. In
the collapsing border model only cells have borders. The FO spec is
very clear on that. So it's absolutely normal that the border specified
on the table-level can reappear on the following pages based on who 
ever

wins.


I see. That seems to be exactly what I expected (although again, I 
described it in the wrong terms).


To put it correctly: since the table before-border wins over header 
before-border, it becomes the competing border for the before-borders 
of the cells in the first row of the header. If all the cells in the 
header's first row have the same before-border, the table's 
before-border then becomes the before-border for all of them.


Sorry for my being unclear. The question was stated in terms of the 
phase I'm currently working on: resolving the border-conflicts between 
the table and its header/footer/bodies, and those between the 
header/first body, body/body, last body/footer. The deeper table 
elements will be something for next week.




(so in this simplified case the after-border on one page
will *always* be the same as the before-border on the next)?


No, I don't think so. I believe the collapsing only happens between two
effectively adjacent cells, i.e., translated to one of our stages, more
located in the area tree stage than in the FO tree stage, if you know
what I mean. But I'm not sure here, because I think the spec is really
not that clear in this little detail. But I'd also think it would be
strange if the border after from the previous page would bleed over to
the next page in this way.


OK, that means resolving after/before border conflicts between two 
bodies would need to be deferred to layout.


Thanks for the useful comments.

BTW: since it is my intention to facilitate the job of the layout 
package in this matter, I'm considering adding BorderInfo instances 
(although I'm not sure where exactly) that keep the resolved info to 
use precisely in these layout-specific cases. What I mean is: even if 
the FOTree lacks some of the context, there is always the fact that it 
is a possibility (however remote) to have a page-break between two body 
elements.
We could say: the BorderInfo to use in 95% of the cases is the one that 
is immediately available in the element's CommonBorderPaddingBackground 
instance, in the other 5% it's another one, available 'over there' 
(wherever that is). Layout would then not need to re-evaluate, but pick 
up the width from that 'special' BorderInfo instance.

Does this sound like a sane thing?


Cheers,

Andreas

Re: Collapsing borders: FOTree stage -- progress update

[Jeremias Maerki]

On 27.08.2005 21:33:44 Andreas L Delmelle wrote:
> On Aug 27, 2005, at 09:09, Jeremias Maerki wrote:
> 
> > Ok, the shock is gone. Thank you for reassuring me that you know what
> > you do. That was my biggest concern. I'm happy that you can reuse some
> > of my code. Finally, someone can use something I wrote to make better
> > progress. Normally, it's the other way around. :-)
> 
> FWIW, I noticed that as well.
> 
> > So I'm wishing you the best of luck and I will assist where I can.
> 
> Thanks. I already have a few remarks, but I'm not sure that you can 
> offer assistance. This is mainly because there is an inherent 
> difficulty in that XSL-FO 1.0 refers entirely to CSS for 
> border-resolution rules, but CSS was written with HTML in mind... It's 
> all so much simpler if there exists no such thing as page-breaks and 
> you have to deal with one continuous table. Maybe this issue should be 
> addressed at W3C? It's understandable that the XSL-FO WG wanted very 
> much to avoid having to duplicate rules that are already defined in 
> other Recommendations, but simply pointing to CSS, which was clearly 
> meant for non-paginated layout, seems to leave too much room for 
> implementation-dependent behavior...
> 
> I'm wondering, for instance, whether the table's before-border specs 
> are only relevant for the first page that is spanned by the table. For 
> example: in case the table has a header (and 
> omit-header-at-break="false"), and the table's before-border wins, then 
> it can still *appear* on the following pages (but that will be because 
> it *is* the header's before-border).

No, the table only has an own border in the separate border model. In
the collapsing border model only cells have borders. The FO spec is
very clear on that. So it's absolutely normal that the border specified
on the table-level can reappear on the following pages based on who ever
wins.

> Another one to chew on: start from a table without header/footer which 
> does have multiple bodies. Suppose also that there are no borders 
> specified on any elements other than the bodies (for the sake of 
> simplicity). Now, if it turns out that a page-break occurs right in 
> between the two bodies, does this mean that the later body's 
> before-border still must be collapsed with the earlier body's 
> after-border (so in this simplified case the after-border on one page 
> will *always* be the same as the before-border on the next)?

No, I don't think so. I believe the collapsing only happens between two
effectively adjacent cells, i.e., translated to one of our stages, more
located in the area tree stage than in the FO tree stage, if you know
what I mean. But I'm not sure here, because I think the spec is really
not that clear in this little detail. But I'd also think it would be
strange if the border after from the previous page would bleed over to
the next page in this way.


Jeremias Maerki

Re: Collapsing borders: FOTree stage -- progress update

[Andreas L Delmelle]

On Aug 27, 2005, at 09:09, Jeremias Maerki wrote:


Ok, the shock is gone. Thank you for reassuring me that you know what
you do. That was my biggest concern. I'm happy that you can reuse some
of my code. Finally, someone can use something I wrote to make better
progress. Normally, it's the other way around. :-)


FWIW, I noticed that as well.


So I'm wishing you the best of luck and I will assist where I can.


Thanks. I already have a few remarks, but I'm not sure that you can 
offer assistance. This is mainly because there is an inherent 
difficulty in that XSL-FO 1.0 refers entirely to CSS for 
border-resolution rules, but CSS was written with HTML in mind... It's 
all so much simpler if there exists no such thing as page-breaks and 
you have to deal with one continuous table. Maybe this issue should be 
addressed at W3C? It's understandable that the XSL-FO WG wanted very 
much to avoid having to duplicate rules that are already defined in 
other Recommendations, but simply pointing to CSS, which was clearly 
meant for non-paginated layout, seems to leave too much room for 
implementation-dependent behavior...


I'm wondering, for instance, whether the table's before-border specs 
are only relevant for the first page that is spanned by the table. For 
example: in case the table has a header (and 
omit-header-at-break="false"), and the table's before-border wins, then 
it can still *appear* on the following pages (but that will be because 
it *is* the header's before-border).


Another one to chew on: start from a table without header/footer which 
does have multiple bodies. Suppose also that there are no borders 
specified on any elements other than the bodies (for the sake of 
simplicity). Now, if it turns out that a page-break occurs right in 
between the two bodies, does this mean that the later body's 
before-border still must be collapsed with the earlier body's 
after-border (so in this simplified case the after-border on one page 
will *always* be the same as the before-border on the next)?



Cheers,

Andreas

Re: Relative font weights and font selection

[Vincent Hennebert]

Victor Mote a écrit :
As I understand the spec, this works differently from 
font-weight and can be resolved in the FO Tree: just select 
the next expanded value for "wider" or next condensed for 
"narrower". The font selection would be performed only after, 
when it is time to decide e.g. which font the keyword 
"semi-expanded" matches.
That's true that it is an extra-feature that IMO can be 
simulated with a good font configuration file.



Just to be clear, I understand your last sentence to be addressing a
different topic than the first part of this statement. That is, font
configuration won't be at all involved with the *resolution* of font-stretch
in what you have proposed. However, it may be involved from the standpoint
of implementing a resolved font-stretch value in that font-stretch could be
simulated using PostScript or PDF text parameters. Did I understand this
correctly?


Yes, except the end: we agree that it would not be the purpose of the font 
config file to solve font-stretch. What I meant is that we could use a 
workaround by specifying different font families for expanded fonts; e.g. one 
family Times-Normal and one Times-Expanded, instead of one family Times with to 
font-stretch variants, Normal and Expanded. The user, instead of changing the 
font-stretch property, would change the font-family.




For all of this, probably the best approach is for someone to do exactly
what you have done above: suggest changes to the interface that will provide
the information needed.


I'll put the problems of font-stretchability and glyph substitution on my 
personal todo list. I may consider those problems later, when I'm (at last!) 
finished with the font integration work.


Vincent

DO NOT REPLY [Bug 36396] - [PATCH] Testcases for relative positioned background images

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=36396





--- Additional Comments From [EMAIL PROTECTED]  2005-08-27 17:27 ---
Created an attachment (id=16225)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16225&action=view)
The testcases to go into test/layoutengine/testcases.


-- 
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 36396] New: - [PATCH] Testcases for relative positioned background images

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=36396

   Summary: [PATCH] Testcases for relative positioned background
images
   Product: Fop
   Version: 1.0dev
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: general
AssignedTo: fop-dev@xml.apache.org
ReportedBy: [EMAIL PROTECTED]


See http://marc.theaimsgroup.com/?t=11249396831&r=1&w=2. Jeremias suggested
that before fixing the problems appropriate testcases be written. Here they
come. 10 different testcases of which only one (background-image-table1)
produces the desired result. I have not added  yet. That should be
done as part of fixing the problems.

-- 
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 36395] - Common Border and Background Properties not supported on all required objects

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=36395





--- Additional Comments From [EMAIL PROTECTED]  2005-08-27 17:14 ---
Correction: fo:basic-link does support backgrounds. It just doesn't work 
properly.

-- 
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 36395] New: - Common Border and Background Properties not supported on all required objects

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=36395

   Summary: Common Border and Background Properties not supported on
all required objects
   Product: Fop
   Version: 1.0dev
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: page-master/layout
AssignedTo: fop-dev@xml.apache.org
ReportedBy: [EMAIL PROTECTED]


While writing layout engine testcases for background images I noticed that the
"Common Border and Background" properties are not supported on all objects for
which we claim full compliance in the compliance matrix on the website. The
objects appear to include (this list may be incomplete): fo:character,
fo:basic-link, fo:page-number, fo:page-number-citation.

It also appears that while table-header/footer support borders they don't
support backgrounds (at least don't support background images).

-- 
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 36394] - fo:character generates invalid PDF

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=36394





--- Additional Comments From [EMAIL PROTECTED]  2005-08-27 16:48 ---
Wow - that was quick!!!

-- 
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 36394] - fo:character generates invalid PDF

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=36394


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-08-27 16:41 ---
Fixed: http://svn.apache.org/viewcvs?rev=240423&view=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.

Re: FOP website, release preparations: refactoring necessary

[Patrick Paul]

Perfect, I will be working towards something like that.

Patrick Paul

Jeremias Maerki wrote:


Sorry, I got the wrong impression. Since it's a CMS I thought you
suggested we use that. But you're right. The tab structure like Lenya
has it is exactly what we need. I think we'll end up with the following
tabs:

- Home
- 0.20.5
- 1.0dev
- Development

(It's probably best to collapse "Development" and "Design" into one tab.
Too many tabs are not ideal. If anyone has better ideas, please bring'em
up.

On 27.08.2005 15:57:02 Patrick Paul wrote:
 

I was talking about their website (with the two tabs for the different 
versions) , not their product.


Patrick

Jeremias Maerki wrote:

   


Uh, oh. Sorry, but I don't think we'll do that. We don't even have the
infrastructure for a Lenya installation and I wouldn't want to rewrite
our whole website just now. That would distract me too much at this
stage of development. Even the Lenya project uses Forrest for their
website. :-)

On 27.08.2005 04:31:55 Patrick Paul wrote:


 

Ok, so from what I understand you want to do, I think that what the 
Lenya project did looks good.


http://lenya.apache.org/

What do you think ?

Patrick Paul

Jeremias Maerki wrote:

  

   


While we're at it: In preparation for the first release we need to start
thinking about a refactoring of our website. Since FOP 0.20.5 will
probably stay the preferred productive version for some time and FOP
Trunk is substantially different, I'd like to propose doing a version
split like Forrest [1] have done. That would involve factoring out the
version-dependent docs into a separate tab (or something like that), so
we can have info for both versions side-by-side for the time being. I
think stuff like embedding info would become too complicated and
unreadable if we tried to put everything in the same place.

If anyone would like to take the lead here, I'd be grateful. Otherwise,
I will squeeze it in somewhere.

[1] http://forrest.apache.org

Jeremias Maerki






 



Jeremias Maerki




 





Jeremias Maerki


 

Re: FOP website, release preparations: refactoring necessary

[Jeremias Maerki]

Sorry, I got the wrong impression. Since it's a CMS I thought you
suggested we use that. But you're right. The tab structure like Lenya
has it is exactly what we need. I think we'll end up with the following
tabs:

- Home
- 0.20.5
- 1.0dev
- Development

(It's probably best to collapse "Development" and "Design" into one tab.
Too many tabs are not ideal. If anyone has better ideas, please bring'em
up.

On 27.08.2005 15:57:02 Patrick Paul wrote:
> I was talking about their website (with the two tabs for the different 
> versions) , not their product.
> 
> Patrick
> 
> Jeremias Maerki wrote:
> 
> >Uh, oh. Sorry, but I don't think we'll do that. We don't even have the
> >infrastructure for a Lenya installation and I wouldn't want to rewrite
> >our whole website just now. That would distract me too much at this
> >stage of development. Even the Lenya project uses Forrest for their
> >website. :-)
> >
> >On 27.08.2005 04:31:55 Patrick Paul wrote:
> >  
> >
> >>Ok, so from what I understand you want to do, I think that what the 
> >>Lenya project did looks good.
> >>
> >>http://lenya.apache.org/
> >>
> >>What do you think ?
> >>
> >>Patrick Paul
> >>
> >>Jeremias Maerki wrote:
> >>
> >>
> >>
> >>>While we're at it: In preparation for the first release we need to start
> >>>thinking about a refactoring of our website. Since FOP 0.20.5 will
> >>>probably stay the preferred productive version for some time and FOP
> >>>Trunk is substantially different, I'd like to propose doing a version
> >>>split like Forrest [1] have done. That would involve factoring out the
> >>>version-dependent docs into a separate tab (or something like that), so
> >>>we can have info for both versions side-by-side for the time being. I
> >>>think stuff like embedding info would become too complicated and
> >>>unreadable if we tried to put everything in the same place.
> >>>
> >>>If anyone would like to take the lead here, I'd be grateful. Otherwise,
> >>>I will squeeze it in somewhere.
> >>>
> >>>[1] http://forrest.apache.org
> >>>
> >>>Jeremias Maerki
> >>>
> >>>
> >>> 
> >>>
> >>>  
> >>>
> >
> >
> >
> >Jeremias Maerki
> >
> >
> >  
> >



Jeremias Maerki

Re: FOP website, release preparations: refactoring necessary

[Manuel Mall]

On Sat, 27 Aug 2005 09:57 pm, Patrick Paul wrote:
> I was talking about their website (with the two tabs for the
> different versions) , not their product.
>
> Patrick
>
> Jeremias Maerki wrote:
> >Uh, oh. Sorry, but I don't think we'll do that. We don't even have
> > the infrastructure for a Lenya installation and I wouldn't want to
> > rewrite our whole website just now. That would distract me too much
> > at this stage of development. Even the Lenya project uses Forrest
> > for their website. :-)
> >
> >On 27.08.2005 04:31:55 Patrick Paul wrote:
> >>Ok, so from what I understand you want to do, I think that what the
> >>Lenya project did looks good.
> >>
> >>http://lenya.apache.org/
> >>
> >>What do you think ?

That looks good to me.

> >>
> >>Patrick Paul

Manuel

Re: FOP website, release preparations: refactoring necessary

[Patrick Paul]

Answers below

Jeremias Maerki wrote:


Have you seen this page? http://xmlgraphics.apache.org/fop/dev/doc.html

 


Yes I have seen the page, I was just too tired last night to go on.


This should give you everything you need to build the docs. But you will
need to ignore the section about ForrestBot since that only works for
committers. Just use local Forrest by calling "forrest run" after you've
unpacked Forrest 0.7 and set up the environment variables. You can then
simply point your browser to http://localhost: and check the changed
website.

I'd like the changes as SVN diffs ("svn diff >mypatch.diff") attached to
a Bugzilla issue.
http://xmlgraphics.apache.org/fop/dev/index.html#patches
http://xmlgraphics.apache.org/fop/dev/tools.html#patches
 


Ok, I will do that


Thanks a lot for diving into this.
 


My pleasure !

Patrick Paul


On 27.08.2005 06:08:14 Patrick Paul wrote:
 

I have figured out how the documentation files work and how to edit 
them. I still have to figure out how to get the site to build on my 
local machine and then I will be in business.


What way you suggest I send the changes to you ?

Thanks,

Patrick Paul

Jeremias Maerki wrote:

   


Very cool! Thanks a lot! If you need any help, just yell.

On 23.08.2005 14:37:38 Patrick Paul wrote:


 

I would like to take care of that. I should have some free time in the 
next few weeks, so I will start doing a little bit everyday starting 
Wednesday.


Patrick

Jeremias Maerki wrote:

  

   


While we're at it: In preparation for the first release we need to start
thinking about a refactoring of our website. Since FOP 0.20.5 will
probably stay the preferred productive version for some time and FOP
Trunk is substantially different, I'd like to propose doing a version
split like Forrest [1] have done. That would involve factoring out the
version-dependent docs into a separate tab (or something like that), so
we can have info for both versions side-by-side for the time being. I
think stuff like embedding info would become too complicated and
unreadable if we tried to put everything in the same place.

If anyone would like to take the lead here, I'd be grateful. Otherwise,
I will squeeze it in somewhere.

[1] http://forrest.apache.org

Jeremias Maerki





 



Jeremias Maerki




 





Jeremias Maerki


 

Re: FOP website, release preparations: refactoring necessary

[Patrick Paul]

Thanks you very much for your help.

Patrick

Manuel Mall wrote:


Patrick,

assuming you have forrest installed you build by simply typing forrest 
in the directory you checked the sources out from subversion, that is 
the directory where the forrest.properties file is in. The generated 
site is then in build/site.


For delivering changes the following procedure is often followed:

For changes to existing files. Use the subversion diff command and 
capture its output, e.g.


svn diff > mychanges.patch

For new files jar or zip them up unless its only very few.

Then create a BugZilla entry with the title starting with '[PATCH] ...' 
and attach the patch file and if applicable the jar/zip file or the few 
new files individually.


Usually one of the committers will then take care of the rest.

Manuel

On Sat, 27 Aug 2005 12:08 pm, Patrick Paul wrote:
 


I have figured out how the documentation files work and how to edit
them. I still have to figure out how to get the site to build on my
local machine and then I will be in business.

What way you suggest I send the changes to you ?

Thanks,

Patrick Paul

Jeremias Maerki wrote:
   


Very cool! Thanks a lot! If you need any help, just yell.

On 23.08.2005 14:37:38 Patrick Paul wrote:
 


I would like to take care of that. I should have some free time in
the next few weeks, so I will start doing a little bit everyday
starting Wednesday.

Patrick

Jeremias Maerki wrote:
   


While we're at it: In preparation for the first release we need to
start thinking about a refactoring of our website. Since FOP
0.20.5 will probably stay the preferred productive version for
some time and FOP Trunk is substantially different, I'd like to
propose doing a version split like Forrest [1] have done. That
would involve factoring out the version-dependent docs into a
separate tab (or something like that), so we can have info for
both versions side-by-side for the time being. I think stuff like
embedding info would become too complicated and unreadable if we
tried to put everything in the same place.

If anyone would like to take the lead here, I'd be grateful.
Otherwise, I will squeeze it in somewhere.

[1] http://forrest.apache.org

Jeremias Maerki
 


Jeremias Maerki
 



 

Re: FOP website, release preparations: refactoring necessary

[Patrick Paul]

I was talking about their website (with the two tabs for the different 
versions) , not their product.


Patrick

Jeremias Maerki wrote:


Uh, oh. Sorry, but I don't think we'll do that. We don't even have the
infrastructure for a Lenya installation and I wouldn't want to rewrite
our whole website just now. That would distract me too much at this
stage of development. Even the Lenya project uses Forrest for their
website. :-)

On 27.08.2005 04:31:55 Patrick Paul wrote:
 

Ok, so from what I understand you want to do, I think that what the 
Lenya project did looks good.


http://lenya.apache.org/

What do you think ?

Patrick Paul

Jeremias Maerki wrote:

   


While we're at it: In preparation for the first release we need to start
thinking about a refactoring of our website. Since FOP 0.20.5 will
probably stay the preferred productive version for some time and FOP
Trunk is substantially different, I'd like to propose doing a version
split like Forrest [1] have done. That would involve factoring out the
version-dependent docs into a separate tab (or something like that), so
we can have info for both versions side-by-side for the time being. I
think stuff like embedding info would become too complicated and
unreadable if we tried to put everything in the same place.

If anyone would like to take the lead here, I'd be grateful. Otherwise,
I will squeeze it in somewhere.

[1] http://forrest.apache.org

Jeremias Maerki




 





Jeremias Maerki


 

DO NOT REPLY [Bug 36394] New: - fo:character generates invalid PDF

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=36394

   Summary: fo:character generates invalid PDF
   Product: Fop
   Version: 1.0dev
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: pdf renderer
AssignedTo: fop-dev@xml.apache.org
ReportedBy: [EMAIL PROTECTED]


The PDF generated from following simple fo produces the error "Illegal operation
'Tm' outside text object." when viewed in Acrobat.

http://www.w3.org/1999/XSL/Format";
xmlns:svg="http://www.w3.org/2000/svg";>
  

  

  
  

  

  

  


-- 
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: Relative font weights and font selection

[Victor Mote]

Manuel Mall wrote:

> I am with Vincent on this one. Here is the text for "wider" 
> from the spec ("smaller" is defined the same way): 
> The relative keyword "wider" sets the value to the next 
> expanded value above the inherited value (while not 
> increasing it above "ultra-expanded").
> 
> Note how it refers to setting the value of the property. No 
> reference to the font selection process.
> 
> Now contrast that to the definition of "bolder" in the spec: 
> Specifies the next weight that is assigned to a font that is 
> darker than the inherited one. If there is no such weight, it 
> simply results in the next darker numerical value (and the 
> font remains unchanged), unless the inherited value was 
> "900", in which case the resulting weight is also "900".
> 
> Here it talks about weights assigned to fonts, etc.. 
> 
> The two mechanisms sound quite different to me.

The good news here is that this is entirely a client (FOP) matter. If you
change your mind later, we can always add methods to the interface similar
to those used for font-weight.

> > I wish I could be more helpful, but I haven't considered 
> all aspects 
> > of the problem yet and I don't catch the whole point. I'd like to 
> > first finish the font integration work.
> > IMHO this feature is for now not that important. What do other 
> > committers think?
> >
> I am not a committer but I do agree with your sentiments. 
> Probably the most important "side-effect" of the FOray font 
> integration with respect to the font selection process would 
> be support for font family lists in font specifications. This 
> is currently not supported and is in my opinion a compliance 
> "must" case before release (not for the 1.0 pre beta but after that).

I agree that this does not all need to be solved today. I just wanted to
generally acknowledge that the interface is not complete, that there are
issues still to be addressed. And a case could be made that font-family
lists are not properly supported unless the supported character set is
considered. I'll work on making and implementing the interface changes
discussed, and you guys can use them whenever you are ready.

Victor Mote

RE: Relative font weights and font selection

[Victor Mote]

Vincent Hennebert wrote:

> Victor Mote a écrit :
> > I am ignoring font-stretch for now. I am unclear whether it works 
> > similarly to font-weight, or whether it is totally 
> resolvable in the FO Tree.
> > Interestingly, CSS 2.1 (the only version of CSS 2 still 
> available at 
> > W3C) removes font-stretch entirely!!??!!
> 
> As I understand the spec, this works differently from 
> font-weight and can be resolved in the FO Tree: just select 
> the next expanded value for "wider" or next condensed for 
> "narrower". The font selection would be performed only after, 
> when it is time to decide e.g. which font the keyword 
> "semi-expanded" matches.
> That's true that it is an extra-feature that IMO can be 
> simulated with a good font configuration file.

Just to be clear, I understand your last sentence to be addressing a
different topic than the first part of this statement. That is, font
configuration won't be at all involved with the *resolution* of font-stretch
in what you have proposed. However, it may be involved from the standpoint
of implementing a resolved font-stretch value in that font-stretch could be
simulated using PostScript or PDF text parameters. Did I understand this
correctly?

> > For font-weight, there seems to be some ambiguity in the 
> standard(s). 
> > There are two possibilities, and neither CSS 2.1 nor XSL-FO seem to 
> > resolve the
> > matter:
> > 
> > 1. Apply "bolder" and "lighter" to the inherited font to compute a 
> > weight that is applied to the selected font.
> > 2. Select the font, inheriting the weight from the inherited font, 
> > then applying "bolder" and "lighter" to that weight.
> 
> I'd go with 1. Get the inherited font; find a darker one in 
> the fonts database; get its weight value. That's it.
> 
> > In order to move forward, I suggest the addition of the following 
> > methods in
> > org.axsl.font.Font:
> > 
> > public byte nextBolderWeight();
> > public byte nextLighterWeight();
> > public org.axsl.font.Font nextBolderFont();
> > public org.axsl.font.Font nextLighterFont();
> > 
> > This will allow the client application (FOP) to use whichever 
> > algorithm it thinks is appropriate. The bad news is that this ties 
> > each registered font to exactly one font-family, something 
> I was hoping to avoid.
> 
> That seems OK.
> The only interest I see for a font to belong to several 
> families is when there is a specific family (Times, 
> Helvetica) and a generic one (serif, sans-serif...). In this 
> case a generic family would be mapped to a specific one, and 
> I don't think your proposed methods prevents that. Otherwise 
> I don't see much interest to mix several families to build a 
> complete set. The result would be visually bad IMO.
> I may have missed something: I haven't studied that point yet.

I think you understand it perfectly. You are correct on all points: 1)
putting a font in multiple font families is not very important, 2) we can
still alias a font-family to another one.

> > There is another area complexity in font selection that has not yet 
> > been addressed, so I pose it here to Vincent and Manuel especially, 
> > and to any others who wish to comment. The whole issue of 
> whether the 
> > Font has a glyph for the character(s) has not yet been 
> addressed. The 
> > best idea I have for this is as follows:
> > 
> > 1. Add a char to the signature of 
> org.axsl.font.FontServer.selectFont. 
> > This char represents the first char of the text for which 
> the font is 
> > being selected. This allows the selection process to pass by a 
> > font-family if it cannot paint the character.
> 
> So let's assume that I have a line of text to render. IIUC I 
> would use it like this:
> * first call with the first char of the text to get the font 
> that will be generally used
> * an additional call for each character for which there is no 
> glyph in the general font Is that what you mean?

I guess so. It doesn't sound elegant or efficient, but I haven't thought of
a better algorithm. Presumably the common case is that the first font
selected works for all of the text.

> > 2. Add the following method to org.axsl.font.Font:
> > /**
> >  * Examines each character in string to ensure that a 
> glyph exists 
> > in the font for that
> >  * character. If a character has no glyph in the font, the 
> > character's index in string
> >  * is returned.
> >  * @return The index in string of its first character 
> for which no 
> > glyph exists in this
> >  * font. If all characters in the string have glyphs in 
> this font, 
> > -1 is returned.
> >  */
> > public int unavailableChar(String string);
> > 
> > Add also an overridden version of this method with 
> char[] as the 
> > parameter.
> 
> Why not directly return an array of all indexes where there 
> is a missing glyph? 

OK. Probably in a separate method called unavailableChars.

> Or add a beginIndex parameter so that one doesn't have to 
> art

Re: FOP website, release preparations: refactoring necessary

[Manuel Mall]

Patrick,

assuming you have forrest installed you build by simply typing forrest 
in the directory you checked the sources out from subversion, that is 
the directory where the forrest.properties file is in. The generated 
site is then in build/site.

For delivering changes the following procedure is often followed:

For changes to existing files. Use the subversion diff command and 
capture its output, e.g.

svn diff > mychanges.patch

For new files jar or zip them up unless its only very few.

Then create a BugZilla entry with the title starting with '[PATCH] ...' 
and attach the patch file and if applicable the jar/zip file or the few 
new files individually.

Usually one of the committers will then take care of the rest.

Manuel

On Sat, 27 Aug 2005 12:08 pm, Patrick Paul wrote:
> I have figured out how the documentation files work and how to edit
> them. I still have to figure out how to get the site to build on my
> local machine and then I will be in business.
>
> What way you suggest I send the changes to you ?
>
> Thanks,
>
> Patrick Paul
>
> Jeremias Maerki wrote:
> >Very cool! Thanks a lot! If you need any help, just yell.
> >
> >On 23.08.2005 14:37:38 Patrick Paul wrote:
> >>I would like to take care of that. I should have some free time in
> >> the next few weeks, so I will start doing a little bit everyday
> >> starting Wednesday.
> >>
> >>Patrick
> >>
> >>Jeremias Maerki wrote:
> >>>While we're at it: In preparation for the first release we need to
> >>> start thinking about a refactoring of our website. Since FOP
> >>> 0.20.5 will probably stay the preferred productive version for
> >>> some time and FOP Trunk is substantially different, I'd like to
> >>> propose doing a version split like Forrest [1] have done. That
> >>> would involve factoring out the version-dependent docs into a
> >>> separate tab (or something like that), so we can have info for
> >>> both versions side-by-side for the time being. I think stuff like
> >>> embedding info would become too complicated and unreadable if we
> >>> tried to put everything in the same place.
> >>>
> >>>If anyone would like to take the lead here, I'd be grateful.
> >>> Otherwise, I will squeeze it in somewhere.
> >>>
> >>>[1] http://forrest.apache.org
> >>>
> >>>Jeremias Maerki
> >
> >Jeremias Maerki

Re: FOP website, release preparations: refactoring necessary

[Jeremias Maerki]

Have you seen this page? http://xmlgraphics.apache.org/fop/dev/doc.html

This should give you everything you need to build the docs. But you will
need to ignore the section about ForrestBot since that only works for
committers. Just use local Forrest by calling "forrest run" after you've
unpacked Forrest 0.7 and set up the environment variables. You can then
simply point your browser to http://localhost: and check the changed
website.

I'd like the changes as SVN diffs ("svn diff >mypatch.diff") attached to
a Bugzilla issue.
http://xmlgraphics.apache.org/fop/dev/index.html#patches
http://xmlgraphics.apache.org/fop/dev/tools.html#patches

Thanks a lot for diving into this.

On 27.08.2005 06:08:14 Patrick Paul wrote:
> I have figured out how the documentation files work and how to edit 
> them. I still have to figure out how to get the site to build on my 
> local machine and then I will be in business.
> 
> What way you suggest I send the changes to you ?
> 
> Thanks,
> 
> Patrick Paul
> 
> Jeremias Maerki wrote:
> 
> >Very cool! Thanks a lot! If you need any help, just yell.
> >
> >On 23.08.2005 14:37:38 Patrick Paul wrote:
> >  
> >
> >>I would like to take care of that. I should have some free time in the 
> >>next few weeks, so I will start doing a little bit everyday starting 
> >>Wednesday.
> >>
> >>Patrick
> >>
> >>Jeremias Maerki wrote:
> >>
> >>
> >>
> >>>While we're at it: In preparation for the first release we need to start
> >>>thinking about a refactoring of our website. Since FOP 0.20.5 will
> >>>probably stay the preferred productive version for some time and FOP
> >>>Trunk is substantially different, I'd like to propose doing a version
> >>>split like Forrest [1] have done. That would involve factoring out the
> >>>version-dependent docs into a separate tab (or something like that), so
> >>>we can have info for both versions side-by-side for the time being. I
> >>>think stuff like embedding info would become too complicated and
> >>>unreadable if we tried to put everything in the same place.
> >>>
> >>>If anyone would like to take the lead here, I'd be grateful. Otherwise,
> >>>I will squeeze it in somewhere.
> >>>
> >>>[1] http://forrest.apache.org
> >>>
> >>>Jeremias Maerki
> >>>
> >>> 
> >>>
> >>>  
> >>>
> >
> >
> >
> >Jeremias Maerki
> >
> >
> >  
> >



Jeremias Maerki

Re: FOP website, release preparations: refactoring necessary

[Jeremias Maerki]

Uh, oh. Sorry, but I don't think we'll do that. We don't even have the
infrastructure for a Lenya installation and I wouldn't want to rewrite
our whole website just now. That would distract me too much at this
stage of development. Even the Lenya project uses Forrest for their
website. :-)

On 27.08.2005 04:31:55 Patrick Paul wrote:
> Ok, so from what I understand you want to do, I think that what the 
> Lenya project did looks good.
> 
> http://lenya.apache.org/
> 
> What do you think ?
> 
> Patrick Paul
> 
> Jeremias Maerki wrote:
> 
> >While we're at it: In preparation for the first release we need to start
> >thinking about a refactoring of our website. Since FOP 0.20.5 will
> >probably stay the preferred productive version for some time and FOP
> >Trunk is substantially different, I'd like to propose doing a version
> >split like Forrest [1] have done. That would involve factoring out the
> >version-dependent docs into a separate tab (or something like that), so
> >we can have info for both versions side-by-side for the time being. I
> >think stuff like embedding info would become too complicated and
> >unreadable if we tried to put everything in the same place.
> >
> >If anyone would like to take the lead here, I'd be grateful. Otherwise,
> >I will squeeze it in somewhere.
> >
> >[1] http://forrest.apache.org
> >
> >Jeremias Maerki
> >
> >
> >  
> >



Jeremias Maerki

Re: Collapsing borders: FOTree stage -- progress update

[Jeremias Maerki]

Ok, the shock is gone. Thank you for reassuring me that you know what
you do. That was my biggest concern. I'm happy that you can reuse some
of my code. Finally, someone can use something I wrote to make better
progress. Normally, it's the other way around. :-) So I'm wishing you
the best of luck and I will assist where I can. I'm extremely excited
about the prospect of having collapsing borders around. And thanks for
taking this task upon you.

On 27.08.2005 00:01:47 Andreas L Delmelle wrote:
> On Aug 26, 2005, at 21:32, Jeremias Maerki wrote:
> 
> > You got me a little shocked when I read your post.
> 
> Really? Good! Nothing personal, but I always tend to take 
> 'shock-and-awe' to be a sign that I'm on the right track. I remember 
> having driven Glen crazy on a few occasions, and that was precisely 
> *because* I was right --although I was far from certain of it at the 
> time.
> 
> > Now I'm afraid I should have realized earlier on what you're up to.
> 
> Afraid? Why exactly? Because you were so enthusiastic about the 
> possibility of collapsing borders being supported by FOP, and now you 
> fear that this enthusiasm was misplaced (or premature)? Well, I'll do 
> my best not to be discouraged by your fear. :-)
> 
> > I hope you were able to reuse at least a bit of the code I already 
> > wrote for the collapsing
> > border model.
> 
> Sure. That's why that step was completed so quickly. Because there was 
> no need to start from scratch. Resolving the border conflicts in the 
> FOTree will take a little more time, as that approach greatly differs 
> from your initial solution to handle it *all* in layout.
> Still, see my recent reply to Peter Herweg's concerns. Now, apply that 
> to this situation: if you hadn't done that work a few months back and 
> committed it, what I'm doing now would definitely take much longer.
> 
> > As far as I can remember most of that already worked quite well 
> > (everything except element generation, I mean). The reason I stopped 
> > with the collapsing border model was my failure to come up with the 
> > right rules to handle the Knuth element generation for the cases
> > where headers and footers interact with body cells.
> 
> Hmm... I see what you mean, but I'm taking this step (a step back?) 
> precisely because I strongly suspect that the rules for element 
> generation will become more apparent if/when the layout package is made 
> to deal *only* with the layout-specific cases.
> 
> 
> > But I'm really concerned that you're hacking away on something for 
> > which
> > a fundamental problem isn't solved, yet.
> 
> Maybe so, but as I already pointed out somewhere in our discussion back 
> then, the logic behind collapsing borders simply does not belong *in* 
> the layout package. It only has to be *reachable* from there, in case 
> the LM's need to resolve borders for the break/span situations.
> So, is this move necessary? Maybe not. I can't say. Is it desirable? 
> IMO most definitely.
> 
> Sure, it's a risk. Maybe eventually, when having to deal with that 
> 'fundamental' problem, I too will reach a point where I'll be inclined 
> to give up. Then again, maybe, in the meantime some ideas will arise on 
> how to facilitate the eventual solution. I can't predict the future 
> with absolute certainty, but I've got a hunch... Of course, it would be 
> presumptuous to state that I *will* make it work, so I'm not going to. 
> What I *am* going to do is *try* to make it appear more trivial than it 
> is now. Even if it becomes only a tiny bit more trivial, that could 
> well turn out to give us just what we were looking for.
> (In the worst case, by the time I'm done, I will have gained valuable 
> insights into the innards of the properties-, fo- and layout-packages, 
> so *I* can't view that to be a waste of time...)
> 
> > Did you verify beforehand that you understand the interactions between 
> > cells in break-conditions especially with headers and footers present? 
> > That's where I gave up back
> > in May [1].
> 
> I'm aware of the difficulties, but I am currently pretty convinced 
> that, once the first part is completed --the move to the 
> fo.flow/fo.properties packages-- this will somehow become easier to 
> sort out. Strange as it may sound, ATM I (have to) force myself to 
> ignore those interaction problems, as they bear no relation (yet) to 
> what I feel needs to happen in the FOTree. Once this task is finished, 
> layout problems will appear as exactly that: _layout_ problems.
> One thing I didn't mention yet is that 'moving' the logic is actually a 
> big word, since I've yet to remove the references to it from the layout 
> code. Currently 'copying' would perhaps better describe it. So, there's 
> still another opportunity to bump in to ideas: when I'm forced to adapt 
> the layout code to the new situation.
> 
> One thing's for certain: it *will* make a difference, and I can only 
> hope the difference will turn out to be a crucial one.
> 
> 
> Ch