Re: svn commit: r553612 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/Constants.java

[Andreas L Delmelle]

On Jul 5, 2007, at 21:01, [EMAIL PROTECTED] wrote:

Hi all,


Author: adelmelle
Date: Thu Jul  5 12:01:14 2007
New Revision: 553612

URL: http://svn.apache.org/viewvc?view=rev&rev=553612
Log:
Fix for a tiny but very nasty bug...


Stumbled upon this little bug while looking at moving the relative  
font-weight computation to a dedicated PropertyMaker.


Seems to have gone unnoticed since there were only checks for  
relative font-weights in the layout test suite, and apparently, there  
it is compensated for (perhaps due to the order in which the tests  
for EN_LIGHTER and EN_100 are performed... on the Property side, they  
seemed to lead to identical hashes for those EnumProperties in  
Richard's implementation of canonical enums.


Just thought I'd share.


Cheers

Andreas

Re: FOP 0.94

[Simon Pepping]

On Thu, Jul 05, 2007 at 09:39:01AM +0200, Vincent Hennebert wrote:
> Hi guys,
> 
> Title says it all. FOP 0.93 was released the 9th of January. I think
> it's time to release the next version, as many bugs have been corrected
> and many exciting new features added.
> 
> Anyone against a new release?

+1 from me.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.eu

Re: FOP 0.94

[Vincent Hennebert]

Hi Max,

Max Berger a écrit :
> Vincent,
> 
> I would love to have Bug 42785 ( patch to support baseline-shift )
> applied before the release, because then I could release a new plugin
> for the new version. I've read your comment, and I will check with the
> spec which options I have to improve the patch, however this will take a
> little while, and I will hopefully be able to do it latest by this
> weekend. What timeline for the release do you have in mind?

Don't worry, there's not that much a hurry. First we will need to get
approval from the team. Then, keep it for yourself but I fear there may
be some discussion about the release number. Then ideally we should make
up a list of bugs and patches that should be corrected or applied before
releasing. Then there's the documentation update. Then find time to
actually launch the release process (branching, tagging, building,
signing...).

It would be good indeed to have your patch applied before the release.
Being a small patch that should be quite easy anyway. I'll make sure
this will happen.

Cheers,
Vincent

Re: FOP 0.94

[Max Berger]

Vincent,

I would love to have Bug 42785 ( patch to support baseline-shift )  
applied before the release, because then I could release a new plugin  
for the new version. I've read your comment, and I will check with  
the spec which options I have to improve the patch, however this will  
take a little while, and I will hopefully be able to do it latest by  
this weekend. What timeline for the release do you have in mind?


Max Berger
e-mail: [EMAIL PROTECTED]

--
PGP/GnuPG ID: E81592BC   Print: F489F8759D4132923EC4  
BC7E072AB73AE81592BC
For information about me or my projects please see http:// 
max.berger.name



Am 05.07.2007 um 09:39 schrieb Vincent Hennebert:


Hi guys,

Title says it all. FOP 0.93 was released the 9th of January. I think
it's time to release the next version, as many bugs have been  
corrected

and many exciting new features added.

Anyone against a new release?

I'd volunteer to deal with all the release process... unless someone
volunteers even more! However, I would gladly accept any help  
regarding

updating the documentation.

WDYT?
Vincent




PGP.sig
Description: Signierter Teil der Nachricht

DO NOT REPLY [Bug 42813] - keep-together in table-row cutting large inner table

[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=42813


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-07-05 01:50 ---
Hi,

This is the expected behaviour of keep-together="always". If the 
"overflow" property is set to "auto" (as is the default), then FOP 
handles it as if "hidden" were specified (See section 7.21.2 of the 
XSL-FO 1.1 specification). Which makes the block cropped at the bottom 
of the page.

To make the table-row being split over 2 pages only if its content 
wouldn't fit on a page alone, you should specify an integer value for 
keep-together. Unfortunately, only "auto" and "always" are currently 
implemented in FOP.

Sorry,
Vincent


-- 
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 42785] - [PATCH] Support baseline-shift for 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=42785





--- Additional Comments From [EMAIL PROTECTED]  2007-07-05 01:41 ---
(In reply to comment #2)

Hi Max,

Thanks for your patch. However, I'm slightly reluctant to apply it as 
is. I have a few questions:
- I can understand the need for an intrinsic baseline-shift for images, 
  especially if the image represents, say, a mathematical formula... 
  That said, in plain FO I think I would use the alignment-adjust 
  property (XSL-FO 1.1, 7.14.1). Now I easily understand that it would 
  be difficult to store this information separately from the image but, 
  still, shouldn't the image have an intrinsic alignment-adjust instead? 
  The description of alignment-adjust says that this property especially 
  applies to images which lack of a baseline-table. Whereas 
  baseline-shift recreates a whole baseline-table for the area. Granted, 
  this doesn't change many things but I think it would be more 
  consistent.
- IIC, the intrinsic baseline-shift may only be a length? Isn't that 
  limiting? If the image is scaled for whatever reason, then the length 
  no longer makes sense. A percentage would probably be more robust. 
  Especially if it's expressed in terms of the image's height. And guess 
  what, that's exactly the case with alignment-adjust.
  BTW, percentages are the reason why the other FOs return a Length 
  object for their baseline-shift.

> Some other comments while I am at it:
> 
> External graphic dimensions are specified in millipoints (int), where 
> as inline-graphics are specified in pts (float). I have followed the 
> same pattern for this patch, but find it quite inconsitent.

I'm not sure of what you are referring to? For both ExternalGraphic and 
InstreamForeignObject the intrinsic dimensions are specified in 
millipoints.

WDYT?
Thanks,
Vincent


-- 
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 42813] New: - keep-together in table-row cutting large inner table

[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=42813

   Summary: keep-together in table-row cutting large inner table
   Product: Fop
   Version: 0.93
  Platform: PC
   URL: http://http://www.rigasp.com/blog/files/fop-keep-
together-issue.zip
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P2
 Component: awt renderer
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


I set keep-together="always" in a fo:table-row that contains an inner very long
table. If the inner table does not fit the page, it cuts it at the end of the
page and the rest of the table is lost! If I remove the keep-together, the table
is displayed fine in 2 pages.
I include a url with a zip with the fo and pdf files to reproduce the problem

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

[Chris Bowditch]

Vincent Hennebert wrote:


Hi guys,

Title says it all. FOP 0.93 was released the 9th of January. I think
it's time to release the next version, as many bugs have been corrected
and many exciting new features added.


Including collapsing border model ;)



Anyone against a new release?


No, I think it makes sense to do another release. Although we still cant 
name it 1.0 as we previously agreed that we should fix the problems with 
changing IPD before doing a 1.0 release.




I'd volunteer to deal with all the release process... unless someone
volunteers even more! However, I would gladly accept any help regarding
updating the documentation.


+1 from me.

Chris

FOP 0.94

[Vincent Hennebert]

Hi guys,

Title says it all. FOP 0.93 was released the 9th of January. I think
it's time to release the next version, as many bugs have been corrected
and many exciting new features added.

Anyone against a new release?

I'd volunteer to deal with all the release process... unless someone
volunteers even more! However, I would gladly accept any help regarding
updating the documentation.

WDYT?
Vincent