headers
Peter B. West | 12 Sep 2002 04:17
Picon
Picon

Re: Build proposal

J.Pietschmann wrote:
> Keiron Liddle wrote:
> 
>> Can we compile the a jdk1.3 or jdk1.4 version of a file use the:
>> <exclude> with "if" or "unless" attribute.
> 
> 
> Certainly. Points:
> - Is it desirable to have two nearly identical files for the two
>   JDK versions because of just three inserted lines?

Yes, IMO.

>   Yeah, in our specific case  this could be solved by using an
>   artificial intermediate class which is empty for JDK1.3 and
>   contains an implementation for the abstract method in the 1.4
>   case.

Sounds good.

>   However, there could be more substantial differences, in
>   particular if they must be read in context and changed
>   synchronously  with the rest of the code, which means the
>   differences are harder to isolate.
>   (Just for fun: look at the Jimi vs. JAI code)

I haven't done that; but the changes should still be isolable, 
particularly if considered when the the whizz-bang new features of jdk 
1.10 are first introduced.  Then its a matter of ensuring that new code 
is written with an eye to the supported jdks.  Rhett may be able to ease
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Cavanagh | 12 Sep 2002 05:54
Picon

Re: keep-with-next(broken)

Hi

I too would like to see the keeps function fixed.

I am currently using a table with these attributes in the row element:
<fo:table-row keep-with-next.within-page="always"
keep-together.within-page="always">

This does not seem to have any effect. Can anyone suggest any alternatives?

<http://dmit.va.com.au/cocoon/display_Works/1-90000/1-300/display_Works_16.x
ml?pdf=xsl_course_pdf>

Here is a page with my output it is all in a table but I would prefer to use
a region for the far left column but when I tried this the output was
corrupted in Adobe Acrobat 5.0.5.

Any tips greatly appreciated.

Regards

Tim Cavanagh
Permalink | Reply | 1 comment |
headers
John Gentilin | 12 Sep 2002 10:16

more table centering

Sorry for the cross post, was not sure of the list, bug or
operator error.

I have read on the list, a mechanism to centre tables with

<fo:table width="100%"  table-layout="fixed">
...
</fo:table>

which seems to work well for me using 20.4.

What I have found is if the <fo:table> statement is
wrapped with an <fo:block> statement, the implementation
breaks and the table is no longer stretched to fit the 100%
of the page.

Is this expected behaviour ?

I am assuming that the table is  expanding to a 100% of the
block but the block is only as big as the table is required to
be. i.e. < 100%. I tried to add  width="100%" to the <fo:block>
but it had no effect.

Regards
John G
Permalink | Reply | 0 comments |
headers
bugzilla | 12 Sep 2002 11:18
Picon
Favicon

DO NOT REPLY [Bug 12564] New: - PDFTextPainter won't find any fop embedded fonts

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12564>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12564

PDFTextPainter won't find any fop embedded  fonts

           Summary: PDFTextPainter won't find any fop embedded  fonts
           Product: Fop
           Version: 0.20.4
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: svg
        AssignedTo: fop-dev <at> xml.apache.org
        ReportedBy: michael.maier <at> vivai.de

By setting strokeSVGText to false in the user configuration file to let all text is drawn into 
PDF using the PDF text commands no embedded font is used because the 
PDFTextPainter cannot find any font in its FontInfo-Object. 

The reason is a bug in the method "paint" of PDFTextPainter. The method tries to find the 
font defined by name, style and weight:
...
                if (fi.hasFont(name, weight, style )) {
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla | 12 Sep 2002 11:25
Picon
Favicon

DO NOT REPLY [Bug 12565] New: - Embedding SVG tags like font-face causes error message and will be ignored

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12565>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12565

Embedding SVG tags like font-face causes error message and will be ignored

           Summary: Embedding SVG tags like font-face causes error message
                    and will be ignored
           Product: Fop
           Version: 0.20.4
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: svg
        AssignedTo: fop-dev <at> xml.apache.org
        ReportedBy: michael.maier <at> vivai.de

That means that the svg-tags 
   font-face, font-face-uri and font-face-src 
can't be used in embedding svg in the "fo:instream-foreign-object" tag.

Solution: In the method setupSVG of the SVGElementMapping class add the following 
lines:
...
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla | 12 Sep 2002 11:30
Picon
Favicon

DO NOT REPLY [Bug 12566] New: - PDFTextPainter won't find any fop embedded fonts

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12566>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12566

PDFTextPainter won't find any fop embedded  fonts

           Summary: PDFTextPainter won't find any fop embedded  fonts
           Product: Fop
           Version: 0.20.4
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: svg
        AssignedTo: fop-dev <at> xml.apache.org
        ReportedBy: michael.maier <at> vivai.de

By setting strokeSVGText to false in the user configuration file to let all text is drawn into 
PDF using the PDF text commands no embedded font is used because the 
PDFTextPainter cannot find any font in its FontInfo-Object. 

The reason is a bug in the method "paint" of PDFTextPainter. The method tries to find the 
font defined by name, style and weight:
...
                if (fi.hasFont(name, weight, style )) {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keiron Liddle | 12 Sep 2002 11:43

block positioning

Hi All,

I'm trying to work out how to specify the block areas for table cells
(and columns, rows).

It seems that the areas should be absolutely positioned blocks.
For the position of absolutely positioned blocks it says that the block
is positioned "with respect to the the box's containing block".

This also means that how block-container is handled is wrong. Since
span-reference-area and flow-reference-area are block areas. Then
absolute position will be relative to the flow-reference-area if it is
under the flow. (I think it is also creating too many spans at the
moment).

Does this make sense.
It would mean that the actual position of an absolutely positioned
block-container will depend on where the parent block is. Which isn't
exactly absolute.

Keiron.
Permalink | Reply | 0 comments |
headers
jaccoud | 12 Sep 2002 15:29
Picon

Re: problems centering image in a table-cell


The row and cell dimensions are fine. My problem is with centering and
scaling the image so it fits correctly into the cell. Inserting a square
3x3 subtable and using the external rows and coluns to emulate padding does
work, but you must agree that it is a awful workaround (this is actually
what the internal padding and margin objects should do...).  I'll try to
cope with the limitations.
Thanks.

=============================================
Marcelo Jaccoud Amaral
Petrobrás (http://www.petrobras.com.br)
mailto:jaccoud <at> petrobras.com.br
voice: +55 21 2534-3485
fax: +55 21 2534-1809
=============================================
<>< Re: deemed!

                                                                                                                                        
                      "J.Pietschmann"                                                                                                   
                      <j3322ptm <at> yahoo.d        Para:     fop-dev <at> xml.apache.org                                                         
                      e>                       cc:                                                                                      
                                               Assunto:  Re: problems centering image in a table-cell                                   
                      11/09/2002 17:33                                                                                                  
                      Favor responder a                                                                                                 
                      fop-dev                                                                                                           

jaccoud <at> petrobras.com.br wrote:
> Hi
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rhett Aultman | 12 Sep 2002 16:31

RE: Build proposal


This seems to be getting to be a hotter topic, so let me just ask this- my work on the dependency-resolving
classloader was happening pretty lazily because it didn't seem to be such an important thing when I
started on it.  Now that we're seeing problems with doing generated source, etc, should I really start
stepping up on this and get that classloader out?  Do we maybe want to devote a little more discussion to it
and how we want to use it?  It might help get the stone of conditional compilation off of our backs better.

-----Original Message-----
From: Peter B. West [mailto:pbwest <at> powerup.com.au]
Sent: Wednesday, September 11, 2002 10:17 PM
To: fop-dev <at> xml.apache.org
Subject: Re: Build proposal

I haven't done that; but the changes should still be isolable, 
particularly if considered when the the whizz-bang new features of jdk 
1.10 are first introduced.  Then its a matter of ensuring that new code 
is written with an eye to the supported jdks.  Rhett may be able to ease 
the difficulties here.
Permalink | Reply | 3 comments |
headers
Jeremias Maerki | 12 Sep 2002 18:04
Picon
Favicon

Re: Build proposal

My brain is currently humming over this topic. I'm reconsidered the
copy/filter approach Jörg favors. I've locally renamed
PDFGraphics2D.java to PDFGraphics2D.javat (t=template). Like this it
shouldn't appear as a template in any IDE. The filtered file is
generated to the new build/gensrc directory (which needs to be specified
as a source directory in an IDE) and compiled from there. It works
pretty well here. Anyone against going this way for now? I'm ready to
commit the refactored build (to HEAD).

I hope your classloaders will be helpful in providing an all-compatible
FOP during runtime at some point. But right now, I'm more concerned
about the maintenance of the source files. There are several questions
bubbling up:
- Do we really have to have copies of each class (one for 1.3, one for
  1.4 etc)?
- Can we really reduce redundancy to a minimum with clever refactoring?
- Could dynamic proxies (since JDK 1.3) be a helpful tool to overcome
  certain problems?
- What's the performance impact of possible solutions during runtime?
- How well do possible solutions work with IDEs?
- What's the ideal directory structure to hold our sources?

By the way: Are you aware of the classloader framework (sub-subproject
"loader") that is currently being developed at Avalon Excalibur by Peter
Donald? Maybe it's worth having a glance at it. Don't know about the
status, though.

On 12.09.2002 16:31:13 Rhett Aultman wrote:
> 
> This seems to be getting to be a hotter topic, so let me just ask this-
(Continue reading)

Permalink | Reply | 2 comments |

Gmane