Re: [GSoC] Auto-table layout questions

[Jeremias Maerki]

On 17.08.2006 04:00:30 Patrick Paul wrote:
> Jeremias Maerki wrote:
> 
> >Patrick,
> >
> >your ICLA hasn't shown up, yet. The last batch of ICLAs was committed
> >2006-07-31 so if you sent it after that date, it may show up in the next
> >batch which I hope will be soon.
> >  
> >
> It was sent after august first, around the 2nd or 3rd of august. I hope 
> it will show up reel soon.

Unfortunately, it hasn't. Jim Jagielski has recorded another batch on
Tuesday where your name was still missing. Sounds to me like something
went bad with the fax. Shrug. :-(

What you can do if you have a scanner, is:

> Therefore, we are now accepting readable scanned images,
> sent via Email, but ONLY under the following conditions:
> 
>1. The Email MUST be sent to [EMAIL PROTECTED]
>   AND [EMAIL PROTECTED]
> 
>2. Once received and verified as readable, the iclas.txt
>   file will be updated with the information. Updating
>   of the iclas.txt file will follow the same procedure
>   as currently implemented: any officer can add an
>   entry but it does not become "official" until
>   acked and moved to the secretary's section of the
>   file.

So, if you put me ([EMAIL PROTECTED]) in the "To:" list of that mail
you're already ok on the ICLA side and we don't have any further delays.
I can also start up my fax software and you can send me that fax again
and I'll handle the rest. If you want to do that, just contact me over
IM.

> >Have you made any progress on your side? Everything working out?
> >  
> >
> I'm getting there... I've implemented a basic auto table layout but I 
> still need to get the whole split done for the 
> InlineElement.getNextKnuthElements. Currently I the element lists are 
> created twice in order to determine the optimal width of each column.
> 
> I am currently preparing some content to update the wiki page and 
> explain everything... I have to learn to communicate *much* more.

Hmm, yeah, that wouldn't hurt. Remember that the GSoC ends next Monday.

I'll take a look at your initial draft patch ASAP.

> Patrick Paul
> 
> >On 07.08.2006 02:58:57 Patrick Paul wrote:
> >  
> >
> >>Jeremias Maerki wrote:
> >>
> >>
> >>
> >>>BTW, Patrick, when I checked the ICLA status of you and Vincent I saw
> >>>that you still don't have an ICLA on file with the ASF. Please sign and 
> >>>send
> >>>(i.e. fax) one to the ASF secretary:
> >>>http://www.apache.org/licenses/#clas
> >>>
> >>>Thanks.
> >>>
> >>>
> >>>Jeremias Maerki
> >>>
> >>>  
> >>>
> >>Hi Jeremias,
> >>
> >>I've been offline most of the time this past week.
> >>
> >>I have faxed my ICLA a few days ago, so I'm hoping it is on file with 
> >>the ASF by now. Please let me know if its not.
> >>
> >>Thank you,
> >>
> >>Patrick
> >>
> >>
> >
> >
> >
> >Jeremias Maerki
> >
> >
> >  
> >



Jeremias Maerki

DO NOT REPLY [Bug 40271] - auto table layout -- dirty draft

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





--- Additional Comments From [EMAIL PROTECTED]  2006-08-17 01:59 ---
Created an attachment (id=18726)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=18726&action=view)
Patch with basic auto table


-- 
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: [GSoC] Auto-table layout questions

[Patrick Paul]

Jeremias Maerki wrote:


Patrick,

your ICLA hasn't shown up, yet. The last batch of ICLAs was committed
2006-07-31 so if you sent it after that date, it may show up in the next
batch which I hope will be soon.
 

It was sent after august first, around the 2nd or 3rd of august. I hope 
it will show up reel soon.



Have you made any progress on your side? Everything working out?
 

I'm getting there... I've implemented a basic auto table layout but I 
still need to get the whole split done for the 
InlineElement.getNextKnuthElements. Currently I the element lists are 
created twice in order to determine the optimal width of each column.


I am currently preparing some content to update the wiki page and 
explain everything... I have to learn to communicate *much* more.


Patrick Paul


On 07.08.2006 02:58:57 Patrick Paul wrote:
 


Jeremias Maerki wrote:

   


BTW, Patrick, when I checked the ICLA status of you and Vincent I saw
that you still don't have an ICLA on file with the ASF. Please sign and send
(i.e. fax) one to the ASF secretary:
http://www.apache.org/licenses/#clas

Thanks.


Jeremias Maerki

 


Hi Jeremias,

I've been offline most of the time this past week.

I have faxed my ICLA a few days ago, so I'm hoping it is on file with 
the ASF by now. Please let me know if its not.


Thank you,

Patrick
   





Jeremias Maerki


 

DO NOT REPLY [Bug 40271] New: - auto table layout -- dirty draft

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

   Summary: auto table layout -- dirty draft
   Product: Fop
   Version: all
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: page-master/layout
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


Here is a first patch for the auto table layout. It will be changing greatly in
the next few days.

-- 
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 40270] - Make list item EndOfNode() method agile to strict-validation

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





--- Additional Comments From [EMAIL PROTECTED]  2006-08-16 19:45 ---
Created an attachment (id=18725)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=18725&action=view)
Patch for AbstractListItemPart.java


-- 
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 40270] New: - Make list item EndOfNode() method agile to strict-validation

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

   Summary: Make list item EndOfNode() method agile to strict-
validation
   Product: Fop
   Version: 1.0dev
  Platform: All
OS/Version: All
Status: NEW
  Keywords: PatchAvailable
  Severity: normal
  Priority: P2
 Component: fo tree
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


[PATCH] This patch is needed to compensate for an error with Microsoft's Word
2003 WordprocessinML style sheet "Word2FO.xsl". McKesson is close to using FOP
at a pilot site and it would greatly help us if this change were made. I highly
doubt that we would experience a timely turn-around from Microsoft.

:::
As per Andreas Delmelle:

Hmm... We already allow table-bodies without child-nodes if strict validation is
turned off, so might as well add this. Not too much harm, I guess.

If it is producing list-item-labels without content --at least an empty block
would suffice-- then the stylesheet should be altered. It is resulting in FO
that does not adhere to the rules in the XSL-FO Rec, so it would be more
reasonable to change the stylesheet.

Either it should create an 'empty' list-item, with both label and body at least
containing an empty block, or it should not create a list-item at all.

:::
To reproduce:


 

Which causes the exception:

org.apache.fop.fo.ValidationException: null:2:26031: Error(2/26031):
fo:list-item-label is missing child elements. 
Required Content Model: marker* (%block;)+
at
org.apache.fop.fo.FONode.missingChildElementError(FONode.java:407)
at
org.apache.fop.fo.flow.AbstractListItemPart.endOfNode(AbstractListItemPa
rt.java:68)
at
org.apache.fop.fo.flow.ListItemLabel.endOfNode(ListItemLabel.java:49)
at
org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.j
ava:378)
at
org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:194)
at
org.apache.xalan.transformer.TransformerIdentityImpl.endElement(Transfor
merIdentityImpl.java:1103)
at
org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
at
org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown
Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDis
patcher.dispatch(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unkno
wn Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
Source)
at
org.apache.xalan.transformer.TransformerIdentityImpl.transform(Transform
erIdentityImpl.java:494)
  . . .

:::
To get around this I modified the endOfNode() method in
org.apache.fop.fo.flow.AbstractListItemPart to only throw this exception if
strict validation is configured. A patch file containing this modification is
attached.

-- 
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 40269] New: - Cannot open the PDF file which generated by FOP in Adobe Illustrator

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

   Summary: Cannot open the PDF file which generated by FOP in Adobe
Illustrator
   Product: Fop
   Version: 0.20.5
  Platform: Other
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: pdf
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


We are having a problem opening the pdf files that are being generated with 
XSL-FO. We need to open the file in Adobe Illustrator to look at the font 
sizes to make sure they are correct. We currently get this message when we try 
to open the file:
 
Could not create internal representation of XMP metadata. 

Thanks,
Kevin

-- 
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: [EMAIL PROTECTED]: Project xml-fop-maintenance (in module xml-fop-maintenance) failed

[Jeremias Maerki]

Uhm, my bad. I seem to have forgotten to upload the necessary change.
Have done it now:
http://svn.apache.org/viewvc/gump/metadata/project/xml-fop-maintenance.xml?view=markup

BTW, we could even think about switching off the Gump run for the
maintenance branch. We won't really do anything there anymore and not
referencing Batik directly sort of defeats the purpose of. Cocoon is the
only project referencing the maintenance branch (AFAIK) but they
switched to Maven which does not work with Gump, yet. WDYT?

On 16.08.2006 12:16:41 Chris Bowditch wrote:
> [EMAIL PROTECTED] wrote:
> 
> >>[javac] /x1/gump/public/workspace/xml-fop-
> >>maintenance/build/src/org/apache/fop/svg/PDFTranscoder.java:233: 
> >>
> > 
> > getViewTransform(java.lang.String,org.w3c.dom.Element,float,float,org.apache.
> > 
> >>batik.bridge.BridgeContext) in org.apache.batik.bridge.ViewBox cannot be 
> > 
> > 
> >>applied to (java.lang.String,org.w3c.dom.svg.SVGSVGElement,float,float)
> >>[javac] Px = ViewBox.getViewTransform(ref, root, width, 
> > 
> > height);
> > 
> >>[javac] ^
> > 
> > 
> > What do we want to do about this?
> > In trunk this method now takes the BridgeContext (which I'm sure the
> > maintenance code has available) so it can report line numbers in errors.
> > The code will work fine if the BridgeContext is null (just no line 
> > numbers).
> > 
> > Is there an expectation that fop-maintenance should work with trunk 
> > Batik?
> 
> No. fop-maintenance only works with an old snapshot of Batik, why is it 
> trying to use Batik trunk?
> 
> Chris
> 



Jeremias Maerki

Re: [EMAIL PROTECTED]: Project xml-fop-maintenance (in module xml-fop-maintenance) failed

[Chris Bowditch]

[EMAIL PROTECTED] wrote:


   [javac] /x1/gump/public/workspace/xml-fop-
maintenance/build/src/org/apache/fop/svg/PDFTranscoder.java:233: 



getViewTransform(java.lang.String,org.w3c.dom.Element,float,float,org.apache.

batik.bridge.BridgeContext) in org.apache.batik.bridge.ViewBox cannot be 




applied to (java.lang.String,org.w3c.dom.svg.SVGSVGElement,float,float)
   [javac] Px = ViewBox.getViewTransform(ref, root, width, 


height);


   [javac] ^



What do we want to do about this?
In trunk this method now takes the BridgeContext (which I'm sure the
maintenance code has available) so it can report line numbers in errors.
The code will work fine if the BridgeContext is null (just no line 
numbers).


Is there an expectation that fop-maintenance should work with trunk 
Batik?


No. fop-maintenance only works with an old snapshot of Batik, why is it 
trying to use Batik trunk?


Chris

Re: [EMAIL PROTECTED]: Project xml-fop-maintenance (in module xml-fop-maintenance) failed

[thomas . deweese]

Hi all,

Sam Ruby <[EMAIL PROTECTED]> wrote on 08/15/2006 08:35:08 AM:

> Project xml-fop-maintenance has an issue affecting its community 
integration.
> This issue affects 1 projects,

> [javac] /x1/gump/public/workspace/xml-fop-
> maintenance/build/src/org/apache/fop/svg/PDFTranscoder.java:233: 
> 
getViewTransform(java.lang.String,org.w3c.dom.Element,float,float,org.apache.
> batik.bridge.BridgeContext) in org.apache.batik.bridge.ViewBox cannot be 

> applied to (java.lang.String,org.w3c.dom.svg.SVGSVGElement,float,float)
> [javac] Px = ViewBox.getViewTransform(ref, root, width, 
height);
> [javac] ^

What do we want to do about this?
In trunk this method now takes the BridgeContext (which I'm sure the
maintenance code has available) so it can report line numbers in errors.
The code will work fine if the BridgeContext is null (just no line 
numbers).

Is there an expectation that fop-maintenance should work with trunk 
Batik?
We could add the old signature (deprecated) that just calls the new 
signature
with 'null' for the BridgeContext.

Re: Some comments on improving the algorithm for before-floats

[Vincent Hennebert]

Hi Simon,

Ok, I've taken out my LaTeX book again to be sure I understand you.


Vincent,

Your proposal to improve the algorithm for the placement of footnotes
and before-floats sounds fine. A few comments.

'Ideally there would be a configuration setting telling which ratio of
the page should be filled with normal content; if this ratio is null
then pages only made of out-of-line objects would be allowed.' I think
this may be split into several configuration settings:
- The minimum amount of normal content on a page.


OK. This corresponds to the \textfraction parameter, right?



- Whether float pages are allowed. Even when the minimum amount is not
  zero, the user may set this to true.


OK. ...mmmh, found no dedicated LaTeX parameter for that.
\floatpagefraction=0?



- The minimum amount of float content on a float page before it may be
  considered feasible. Only relying on the normal demerits calculation
  for the stretch or shrink may be too restrictive.


Moreover, if the figures are made of images, there is likely to be few
shrink/stretch.
This is also the \floatpagefraction parameter? Actually I don't really
understand this parameter. At least, I don't understand its interest:
this means that underfull float-only pages are acceptable? This looks
weird to me.

But as it would be easy to implement, I can do it. Related question:
would footnotes be allowed on float-only pages, or only before-floats?
This may be useful for books with many many footnotes. But for other
books this can look weird. WDYT? Another config parameter?



In fact, these are configuration parameters in LaTeX.

Regarding the demerits for deferred out-of-line objects, a simple
multiplication with the page difference produces a linear
relation. This may be too weak, and a squared or steeper relation may
be preferable.


No. Period.

Ok, some explanations ;-) This would break the property of optimal
substructure which makes the dynamic programming approach work. In his
thesis, Plass proved that using a squared function leads to an
NP-complete problem. In "Pagination Reconsidered", Brüggeman-Klein et
al. showed that using a linear function is nearer to a human's feelings,
is solvable by dynamic programming, and gives satisfying results. So
I think we may go with it.



Regards, Simon


Thank you,
Vincent