DO NOT REPLY [Bug 4002] - TTFReader unable to handle 3 of 9 Barcode font

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=4002

TTFReader unable to handle 3 of 9 Barcode font





--- Additional Comments From [EMAIL PROTECTED]  2001-11-27 01:36 ---
I have tried with a lot of different commercial and shareware Code 39 (3 of 9) 
Barcode fonts but they all have this problem. In some cases there is a EOF 
exception instead of "Unicode cmap table not present" and then No Such Element 
exception.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Problem in Inner Table border

[lpkhoo]

Hello,

I faced a problem on inner Table border.

My main table have border-width so each table cell can draw the border for
left, right, botton and top. In my document,

one of my table-cell have another table and the inner table border-width is
0 value.

 After run fop, the table-cell border are not draw  which contain inner
table.

I using FOP 0.20.2 to run my document.

Here, I attach my document.

I hope that any one can help.

Thank you

(See attached file: sample.fo)(See attached file: sample.xml)

lpkhoo




sample.fo
Description: Binary data


sample.xml
Description: Binary data

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

CommandLineApps don't work (CVS-Version)

[Michael Bichler]

KONTEXT:
 
CVS-Sourcen: 
xml-fop_20011127051852.tar.gzerzeugt in:   
D:\xml-fop>compiliert:...init: 
[echo] --- Fop 1.0dev [1999-2001] 
 
prepare: [echo] 
Preparing the build directories
 
codegen: [echo] 
Resetting codegen directory [echo] Generating the 
java files from xml resources
 
prepare-jimi: [echo] 
Jimi library is present. Fop installs jimi support.
 
prepare-jai:
 
prepare-trax: [echo] 
JAXP1.1 transforms is present. Installing TRaX support
 
prepare-src:
 
compile: [echo] 
Compiling the sources    [mkdir] Created dir: 
D:\xml-fop\build\classes\org\apache\fop\viewer\resources 
[copy] Copying 9 files to 
D:\xml-fop\build\classes\org\apache\fop\viewer\resources    
[mkdir] Created dir: 
D:\xml-fop\build\classes\org\apache\fop\viewer\Images 
[copy] Copying 5 files to 
D:\xml-fop\build\classes\org\apache\fop\viewer\Images    
[javac] Compiling 774 source files to 
D:\xml-fop\build\classes    [javac] 
D:\xml-fop\build\src\org\apache\fop\tools\anttasks\CompileXMLFiles.java:38: 
Note: interface org.xml.sax.DocumentHandler has been 
deprecated.    
[javac]    
org.xml.sax.DocumentHandler, org.xml.sax.ErrorHandler {    
[javac]    
^    [javac] 
D:\xml-fop\build\src\org\apache\fop\tools\anttasks\CompileXMLFiles.java:97: The 
method void setDocumentLocator(org.xml.sax.Locator) declared in class 
org.apache.fop.tools.anttasks.CompileXMLFiles is not deprecated, but 
overrides a deprecated method of the same signature declared in interface 
org.xml.sax.DocumentHandler.    
[javac] public void setDocumentLocator(Locator locator) 
{    
[javac] 
^    [javac] 
D:\xml-fop\build\src\org\apache\fop\tools\anttasks\CompileXMLFiles.java:101: The 
methodvoid startDocument() declared in class 
org.apache.fop.tools.anttasks.CompileXMLFiles is not deprecated, but 
overrides a deprecated method of the same signature declared in interface 
org.xml.sax.DocumentHandler.    
[javac] public void startDocument() throws SAXException 
{    
[javac] 
^    [javac] 
D:\xml-fop\build\src\org\apache\fop\tools\anttasks\CompileXMLFiles.java:110: The 
methodvoid endDocument() declared in class 
org.apache.fop.tools.anttasks.CompileXMLFiles is not deprecated, but 
overrides a deprecated method of the same signature declared in interface 
org.xml.sax.DocumentHandler.    
[javac] public void endDocument() throws SAXException 
{    
[javac] 
^    [javac] 
D:\xml-fop\build\src\org\apache\fop\tools\anttasks\CompileXMLFiles.java:140: The 
methodvoid startElement(java.lang.String, org.xml.sax.AttributeList) 
declared in class org.apache.fop.tools.anttasks.CompileXMLFiles is not 
deprecated, but overrides a deprecated method of the same signature declared 
in interface org.xml.sax.DocumentHandler.    
[javac] public void startElement(String 
name,    
[javac] 
^    [javac] 
D:\xml-fop\build\src\org\apache\fop\tools\anttasks\CompileXMLFiles.java:149: The 
methodvoid endElement(java.lang.String) declared in class 
org.apache.fop.tools.anttasks.CompileXMLFiles is not deprecated, but 
overrides a deprecated method of the same signature declared in interface 
org.xml.sax.DocumentHandler.    
[javac] public void endElement(String name) throws 
SAXException {    
[javac] 
^    [javac] 
D:\xml-fop\build\src\org\apache\fop\tools\anttasks\CompileXMLFiles.java:153: The 
methodvoid characters(char[], int, int) declared in class 
org.apache.fop.tools.anttasks.CompileXMLFiles is not deprecated, but 
overrides a deprecated method of the same signature declared in interface 
org.xml.sax.DocumentHandler.    
[javac] public void characters(char ch[], int 
start,    
[javac] 
^    [javac] 
D:\xml-fop\build\src\org\apache\fop\tools\anttasks\CompileXMLFiles.java:158: The 
methodvoid ignorableWhitespace(char[], int, int) declared in class 
org.apache.fop.tools.anttasks.CompileXMLFiles is not deprecated, but 
overrides a deprecated method of the same signature declared in interface 
org.xml.sax.DocumentHandler.    
[javac] public void ignorableWhitespace(char ch[], int 
start,    
[javac] 
^    [javac] 
D:\xml-fop\build\src\org\apache\fop\tools\anttasks\CompileXMLFiles.java:163: The 
methodvoid processingInstruction(java.lang.String, java.lang.String) 
declared in class org.apache.fop.tools.anttasks.CompileXMLFiles is not 
deprecated, but overrides a deprecated method of the same signature declared 
in interface org.xml.sax.DocumentHandler.    
[javac] public void processingInstruction(String 
target,    
[javac] 
^    [javac] 
D:\xml-fop\build\src\org\apache\fop\tools\anttasks\CompileXMLFiles.java:65: 
Note: interface org.xml.sax.Parser has been 
deprecated.    
[javac] Parser parser = 
createParser();    
[javac] ^    
[javac] 
D:\xml-fop\build\src\org\apache\fop\tools\anttasks\CompileXMLFiles.ja

Re: Merging jfor into FOP - what's the plan?

[Arved Sandstrom]

Hi, Bertrand

What are your recommendations for someone to come up to speed with RTF? I 
(and possibly others) need to understand RTF better in order to assist.

The existing renderers for PDF, Postscript, XML and AWT can all handle raw 
areas...they do no layout whatsoever. As I understand it, RTF is presented 
to a user-agent which does a fair amount of layout; higher-level structures 
are still present in the RTF. This is not so different from MIF, and in 
fact, when the MIFRenderer was originally written, there _were_ some 
problems (as I recall) in working from the area tree directly. For example, 
MIF understands tables - this information needed to be passed along whereas 
other renderers no longer cared about such semantics.

Since the MIFRenderer is somewhat moribund (I think) then jfor really 
becomes the prototype for a different class of formatter/renderers, 
operating in parallel with the existing code for PDF etc. It would be 
interesting to see if we can do things in such a way so as to resurrect MIF 
also, since I think it never ought to have been a renderer in the first place.

In a sense with RTF and MIF (and HTML for anyone who really desperately 
wants to see FO->HTML) we are talking about translators as opposed to 
formatters and renderers...again, correct me if I am wrong, but the output 
of the translator is presented to a user-agent that will actually be doing 
layout.

Regards,
Arved Sandstrom

At 08:43 AM 11/27/01 +0100, Bertrand Delacretaz wrote:
>Hi Keiron,
>
>If there is not going to be a FOP release in the next few weeks, I 
>agree that a minimal integration does not make sense.
>
>Currently the jfor conversion is driven directly from SAX events, so the 
>first thing that comes to mind is driving it from the FO tree.
>
>You're right that, contrary to print renderers, the RTF one will need to
know 
>about the structure of the original document.
>
>Does the FO tree handle things like attribute inheritance (i.e. a block 
>inherits the font definition from an ancestor block), or is this handled 
>while doing the layout? Such inheritance is currently missing in jfor.
>
>To summarize:
>-jfor needs to know about the original document structure: speaks for option 
>(A), plugging jfor right after the FO tree stage if I understand well.
>
>-BUT jfor could probably benefit from some operations done at the layout 
>stage (attributes inheritance, others?) : speaks for option (B), extending 
>the renderer interface to let the renderers know (cleanly) about the
original 
>document structure.
>
>If you can give me some pointers about where to look at in the code to 
>evaluate (A) and (B), I'll have a look.
>
>- Bertrand
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, email: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 5120] New: - FOP hangs when using SVG

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=5120

FOP hangs when using SVG

   Summary: FOP hangs when using SVG
   Product: Fop
   Version: all
  Platform: Other
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: svg
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


FOP everytime hangs, wenn I embed an SVG-image.
There's another user, who describes the same problem at
http://marc.theaimsgroup.com/?l=fop-dev&m=100682963306791&w=2

-->
Hi,

I have a problem when I try to generate a PDF file from a FOP file that
contains an SVG image. It doesn't matter if the image is inline or if it's
stored as a separate file. My problem is that the PDF file gets generated
but for some reason the java thread "hangs", i.e. even though the work is
finished it doesn't stop executing. Has anyone else encountered this
problem?

Here's the piece of code that I'm using to render the PDF:

Hierarchy hierarchy = Hierarchy.getDefaultHierarchy();
Logger log = hierarchy.getLoggerFor("fop");
log.setPriority(Priority.DEBUG);
Driver driver = new Driver(new InputSource(new
StringReader(template.toString())), outputStream);
driver.setLogger(log);
driver.setRenderer(Driver.RENDER_PDF);
 
driver.addElementMapping("org.apache.fop.fo.StandardElementMapping");
driver.addElementMapping("org.apache.fop.svg.SVGElementMapping");
driver.run();

This code generated this output:

INFO10068   [fop ] (): building formatting object tree
DEBUG   10068   [fop ] (): setting up fonts
INFO10068   [fop ] (): [1]
INFO10068   [fop ] (): Parsing of document complete, stopping
renderer
DEBUG   10068   [fop ] (): Initial heap size: 1569Kb
DEBUG   10068   [fop ] (): Current heap size: 2689Kb
DEBUG   10068   [fop ] (): Total memory used: 1119Kb
DEBUG   10068   [fop ] ():   Memory use is indicative; no GC was
performed
DEBUG   10068   [fop ] ():   These figures should not be used
comparatively
DEBUG   10068   [fop ] (): Total time used: 8993ms
DEBUG   10068   [fop ] (): Pages rendererd: 1
DEBUG   10068   [fop ] (): Avg render time: 8993ms/page

Thanks in advance,

Vladimir Sneblic
Software Engineer
Sytec Resources Limited

Phone:  +64 9 917-4264
Fax:+64 9 355-0070  
Mobile: +64 21 404046
Email:   [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: TTFReader not working with some TTF fonts?

[Hoang Nam]

I have the same problem : an exception  when I try to add Windings font of
Word

Here is the error message :

---
Reading c:\winnt\fonts\wingding.ttf...

Number of glyphs in font: 226
Unicode cmap table not present
java.util.NoSuchElementException: Vector Enumeration
at java.util.Vector$1.nextElement(Vector.java:294)
at org.apache.fop.fonts.TTFFile.createCMaps(Compiled Code)
at org.apache.fop.fonts.TTFFile.readFont(TTFFile.java:404)
at org.apache.fop.fonts.apps.TTFReader.loadTTF(TTFReader.java:181)
at org.apache.fop.fonts.apps.TTFReader.main(TTFReader.java:143)


---

Thanks for any idea !

Nam

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 26, 2001 6:05 PM
Subject: TTFReader not working with some TTF fonts?



Hi,

I'd like to create the font xml file with the TTFReader. If I do it with a
standard windows font (like Verdana), it works. But when I try with some
freefont (TTF), I always have an EOFException... Is it supposed to work
with every TTF fonts?

Thanks

Cheers

Emmanuel Ponette
Euro DB
Place de l'Université, 16
B-1348 Louvain-La-Neuve

Phone: +32 10 47 67 44
Fax:  +32 10 47 67 67


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: TTFReader not working with some TTF fonts?

[Hoang Nam]

Sorry, I found the answer for the following problem  in the mail archives .
Please delete this following question. Thanks !

- Original Message -
From: "Hoang Nam" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 27, 2001 1:29 PM
Subject: Re: TTFReader not working with some TTF fonts?


> I have the same problem : an exception  when I try to add Windings font of
> Word




_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: TTFReader not working with some TTF fonts?

[emmanuel . ponette]

Could you please forward it to me privately ([EMAIL PROTECTED])

Thanks

Emmanuel Ponette
Euro DB
Place de l'Université, 16
B-1348 Louvain-La-Neuve

Phone: +32 10 47 67 44
Fax:  +32 10 47 67 67


   

"Hoang Nam"

  

.fr> cc:   

 Subject: Re: TTFReader not working with 
some TTF fonts?   
27/11/2001 

13:33  

Please respond 

to fop-dev 

   

   





Sorry, I found the answer for the following problem  in the mail archives .
Please delete this following question. Thanks !

- Original Message -
From: "Hoang Nam" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 27, 2001 1:29 PM
Subject: Re: TTFReader not working with some TTF fonts?


> I have the same problem : an exception  when I try to add Windings font
of
> Word




_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 5100] - Useless error message

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=5100

Useless error message





--- Additional Comments From [EMAIL PROTECTED]  2001-11-27 05:21 ---
Perhaps it should #1 be down-graded to WARN (less alarming) and #2 change the
text to read:

 [java] WARNING 10068 [fop  ] (): Text could not fit in it's container

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

problem : centered table in FO

[Cyril Rognon]

Hi list,

I am looking for a way to center a table (not the data in the table
cells) in a page.

I have tried to set padding and margin to a surrounding block but FOP
doesn't pay attention to this...

I have also tried a start-indent but it changes nothing. I am using FOP
0.20.2RC.

What am I doing wrong ?

Thanks

Cyril Rognon

DO NOT REPLY [Bug 5124] New: - fo:block-container is not rendered properly using -pcl option

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=5124

fo:block-container is not rendered properly using -pcl option 

   Summary: fo:block-container is not rendered properly using -pcl
option
   Product: Fop
   Version: all
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The test file border.fo is not rendered properly while output in pcl format.
It seems that
1. the xoffset is not needed, i think anymore -it generates out of bound 
warnings 
2. height? is computed in reverse direction causing  borders to 
be printed wrongly.
   should be +--+-+
 |  | | 
 +--+-+

 and is  +--+-+
 
 +--+-+
 |  | |

I have added y=y+h nearby line 207 in addRect(..) and reset xoffset to 0 to 
quickly fix it but it still needs some more work.

Thanks,
k.j

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Merging jfor into FOP - what's the plan?

[Bertrand Delacretaz]

Hi Arved,

> What are your recommendations for someone to come up to speed with RTF?

I'd recommend to stay away from it unless you really have to ;-)
Seriously, to someone accustomed to clear and well-defined specs, RTF is 
somewhat messy, what it is really is a documented internal format, not a spec 
that has been agreed upon by a carefully-selected comittee.

The RTF spec that we use in jfor is (mostly) V1.5 from Microsoft, who since 
moved on to 1.6 (at least), but apparently 1.5 is the most widely supported 
spec. A google search shows it at http://www.dubois.ws/software/RTF, it might 
be harder to find at Microsoft as it's not the latest.

The rtflib package of jfor (available at www.jfor.org) encapsulates our 
knowledge of RTF and is fairly simple and understandable, but it is still too 
much element-oriented.
One important thing to realize (happened too late here) is that RTF is 
more flow-based or stack-based than element-based: not everything that is 
opened has to be closed, it's more like a flow with embedded attribute 
changes.

> As I understand it, RTF is presented
> to a user-agent which does a fair amount of layout; higher-level structures
> are still present in the RTF. 

Right - but there are both structure and presentations codes, so an RTF 
document could be both. 
Jfor has a strong bend towards structure, as usually the user goal is to get 
an editable RTF document, where as much of the original document structure 
must be preserved for convenience. 
Precise appearance usually comes second, as applying a new wordprocessor 
style sheet can change a lot of it.

RTF is both a presentation and a structure format, along with a moving target 
due to the "spec" being expanded and rewritten with nearly every new version 
of winword. 
There are a many grey areas in the spec, meaning the only possible test is 
opening the generated RTF in the desired wordprocessors (and often watching 
it crash...).

> 
> This is not so different from MIF
Agreed. We are working with MIF for another project, and didn't choose FOP 
for that because of lack of precise control over the MIF output.

I tend to see these formats as:
-PDF for finished high-quality output ("presentation language"), layout 100% 
done by FOP

-MIF for semi-finished high-quality output ("typography language"), layout 
done by Framemaker according to MIF instructions.

-RTF for editable structure + presentation output ("wordprocessing 
language"), layout done by wordprocessor.

So I fully agree that MIF and RTF "renderers" share a lot in common - 
they must be able to get as much information as possible about the original 
document structure, and in my view do not need any layout computations.

> In a sense with RTF and MIF (and HTML for anyone who really desperately
> wants to see FO->HTML) we are talking about translators as opposed to
> formatters and renderers...

yes - that's why I called jfor a "converter" instead of "formatter"

Without knowing too much about FOP internals, I think a processing chain 
along these lines might help:

parsing if needed
-> SAX events
-> FO attributes processing (validation, inheritance) 
-> StructureRenderer

StructureRenderer is
EITHER Layout + PrintRenderer
OR StructureProcessor (RTF, MIF, etc.)

What we need to find out is how much the existing FOP and these "structure 
renderers" have in common.

- Bertrand

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Bug in

[spam_from_fop_dev]

> I found a bug in  where it can't
> do internal link for fop 0.20.1. During run fop0.20.1, if the
> document have more then one page and the  internal-destination> in one page and  in another page
> then the fop were given me an error " This id already exists in
> document.".

I had this problem too.  It is fixed in 0.20.2RC.

--Phil.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

xpath

[Maneshi Tuli]

Hi ,
I am in one problem ,

I want to count all rows for whom child col   having attribute num='8'  is not null
 i was trying to like this

  row/col[not(@num='8')]
but it counts the col
i want count on row.

plz help me out .

Maneshi Tuli
  212-454-1646 (O)
  732 -882-0353(H)



--

This e-mail may contain confidential and/or privileged information. If you are not the 
intended recipient (or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail. Any unauthorized copying, disclosure or 
distribution of the material in this e-mail is strictly forbidden.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Merging jfor into FOP - what's the plan?

[Peter B. West]

Bertrand et al,

It looks as though the principle of disentangling the FO and Area tree 
builds, with communication by a stream of FOEvents, would also be useful 
in this context.

Peter

Bertrand Delacretaz wrote:

> Hi Arved,
> 
> 
>>What are your recommendations for someone to come up to speed with RTF?
>>
> 
> I'd recommend to stay away from it unless you really have to ;-)
> Seriously, to someone accustomed to clear and well-defined specs, RTF is 
> somewhat messy, what it is really is a documented internal format, not a spec 
> that has been agreed upon by a carefully-selected comittee.
> 
> The RTF spec that we use in jfor is (mostly) V1.5 from Microsoft, who since 
> moved on to 1.6 (at least), but apparently 1.5 is the most widely supported 
> spec. A google search shows it at http://www.dubois.ws/software/RTF, it might 
> be harder to find at Microsoft as it's not the latest.
> 
> The rtflib package of jfor (available at www.jfor.org) encapsulates our 
> knowledge of RTF and is fairly simple and understandable, but it is still too 
> much element-oriented.
> One important thing to realize (happened too late here) is that RTF is 
> more flow-based or stack-based than element-based: not everything that is 
> opened has to be closed, it's more like a flow with embedded attribute 
> changes.
> 
> 
>>As I understand it, RTF is presented
>>to a user-agent which does a fair amount of layout; higher-level structures
>>are still present in the RTF. 
>>
> 
> Right - but there are both structure and presentations codes, so an RTF 
> document could be both. 
> Jfor has a strong bend towards structure, as usually the user goal is to get 
> an editable RTF document, where as much of the original document structure 
> must be preserved for convenience. 
> Precise appearance usually comes second, as applying a new wordprocessor 
> style sheet can change a lot of it.
> 
> RTF is both a presentation and a structure format, along with a moving target 
> due to the "spec" being expanded and rewritten with nearly every new version 
> of winword. 
> There are a many grey areas in the spec, meaning the only possible test is 
> opening the generated RTF in the desired wordprocessors (and often watching 
> it crash...).
> 
> 
>>
>>This is not so different from MIF
>>
> Agreed. We are working with MIF for another project, and didn't choose FOP 
> for that because of lack of precise control over the MIF output.
> 
> I tend to see these formats as:
> -PDF for finished high-quality output ("presentation language"), layout 100% 
> done by FOP
> 
> -MIF for semi-finished high-quality output ("typography language"), layout 
> done by Framemaker according to MIF instructions.
> 
> -RTF for editable structure + presentation output ("wordprocessing 
> language"), layout done by wordprocessor.
> 
> So I fully agree that MIF and RTF "renderers" share a lot in common - 
> they must be able to get as much information as possible about the original 
> document structure, and in my view do not need any layout computations.
> 
> 
>>In a sense with RTF and MIF (and HTML for anyone who really desperately
>>wants to see FO->HTML) we are talking about translators as opposed to
>>formatters and renderers...
>>
> 
> yes - that's why I called jfor a "converter" instead of "formatter"
> 
> Without knowing too much about FOP internals, I think a processing chain 
> along these lines might help:
> 
> parsing if needed
> -> SAX events
> -> FO attributes processing (validation, inheritance) 
> -> StructureRenderer
> 
> StructureRenderer is
> EITHER Layout + PrintRenderer
> OR StructureProcessor (RTF, MIF, etc.)
> 
> What we need to find out is how much the existing FOP and these "structure 
> renderers" have in common.
> 
> - Bertrand
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 
> 


-- 
Peter B. West  [EMAIL PROTECTED]  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Merging jfor into FOP - what's the plan?

[Scott Sanders]

The latest RTF Spec (1.7), pertaining to Word 2002 is at:

http://download.microsoft.com/download/Word2002/Install/1.7/W98NT42KMeXP
/EN-US/W2KRTFSF.exe

Self Extracting exe with the Word doc inside.

Scott Sanders


-Original Message-
From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, November 27, 2001 3:40 AM
To: [EMAIL PROTECTED]
Subject: Re: Merging jfor into FOP - what's the plan?

Hi Arved,

> What are your recommendations for someone to come up to speed with
RTF?

I'd recommend to stay away from it unless you really have to ;-)
Seriously, to someone accustomed to clear and well-defined specs, RTF is

somewhat messy, what it is really is a documented internal format, not a
spec 
that has been agreed upon by a carefully-selected comittee.

The RTF spec that we use in jfor is (mostly) V1.5 from Microsoft, who
since 
moved on to 1.6 (at least), but apparently 1.5 is the most widely
supported 
spec. A google search shows it at http://www.dubois.ws/software/RTF, it
might 
be harder to find at Microsoft as it's not the latest.

The rtflib package of jfor (available at www.jfor.org) encapsulates our 
knowledge of RTF and is fairly simple and understandable, but it is
still too 
much element-oriented.
One important thing to realize (happened too late here) is that RTF is 
more flow-based or stack-based than element-based: not everything that
is 
opened has to be closed, it's more like a flow with embedded attribute 
changes.

> As I understand it, RTF is presented
> to a user-agent which does a fair amount of layout; higher-level
structures
> are still present in the RTF. 

Right - but there are both structure and presentations codes, so an RTF 
document could be both. 
Jfor has a strong bend towards structure, as usually the user goal is to
get 
an editable RTF document, where as much of the original document
structure 
must be preserved for convenience. 
Precise appearance usually comes second, as applying a new wordprocessor

style sheet can change a lot of it.

RTF is both a presentation and a structure format, along with a moving
target 
due to the "spec" being expanded and rewritten with nearly every new
version 
of winword. 
There are a many grey areas in the spec, meaning the only possible test
is 
opening the generated RTF in the desired wordprocessors (and often
watching 
it crash...).

> 
> This is not so different from MIF
Agreed. We are working with MIF for another project, and didn't choose
FOP 
for that because of lack of precise control over the MIF output.

I tend to see these formats as:
-PDF for finished high-quality output ("presentation language"), layout
100% 
done by FOP

-MIF for semi-finished high-quality output ("typography language"),
layout 
done by Framemaker according to MIF instructions.

-RTF for editable structure + presentation output ("wordprocessing 
language"), layout done by wordprocessor.

So I fully agree that MIF and RTF "renderers" share a lot in common - 
they must be able to get as much information as possible about the
original 
document structure, and in my view do not need any layout computations.

> In a sense with RTF and MIF (and HTML for anyone who really
desperately
> wants to see FO->HTML) we are talking about translators as opposed to
> formatters and renderers...

yes - that's why I called jfor a "converter" instead of "formatter"

Without knowing too much about FOP internals, I think a processing chain

along these lines might help:

parsing if needed
-> SAX events
-> FO attributes processing (validation, inheritance) 
-> StructureRenderer

StructureRenderer is
EITHER Layout + PrintRenderer
OR StructureProcessor (RTF, MIF, etc.)

What we need to find out is how much the existing FOP and these
"structure 
renderers" have in common.

- Bertrand

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

min table or table-cell height?

[Savino, Matt C]

Is there any way to make sure a table border extends to the bottom of the
page (minus margins)?

A picture may help. This is the structure of my document. The '-'s and '|'s
represent actual line borders:

---
| Header (fo:region-before) |
---
  (blank space)
---
| Body |
| (contains data within   |  
|  nested tables)   |
---

The report has up to four sections which can all span multiple pages. The
body part changes but the header stays constant across all 4 sections. Right
now I'm creating the border around the body as a border around table-cells.
Each section of the report is contained within one table-cell. The problem
is that I would like to make sure the bottom border extends to the bottom of
the page (even if the data only spans a few rows) and that the side borders
come down to meet it. 

It seems like this should be a pretty simple problem but I haven't come up
with anything yet. Any help would be greatly appreciated.

Thanks
Matt





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

table alignment.

[lpkhoo]

Hello,

I faced a problem on table alignment. When I run my fop (FOP 0.20.2) I
found the table alignment is always on start

alignment even my table is inside the block. May I know is that any
attribute that can be used for table alignment.

Currently, I tried to used text-align in block. But it doesn't given me any
changes.

Do anyone have any idea of how to solved this problem?

Hope somebody can help me.

Thank you.

lpkhoo








-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: HELP: PDF generation hangs

[Joerg Pietschmann]

Vladimir Sneblic <[EMAIL PROTECTED]> wrote:
> I have a problem when I try to generate a PDF file from a FOP file that
> contains an SVG image. It doesn't matter if the image is inline or if it's
> stored as a separate file. My problem is that the PDF file gets generated
> but for some reason the java thread "hangs", i.e. even though the work is
> finished it doesn't stop executing. Has anyone else encountered this
> problem?

This is a well known problem with the Java runtime, which should
be fixed in JDK 1.4 (along with a few other major annoynaces).
What probably happens is that Batik uses AWT functionality for
SVG rendering, which often (but not always) causes the graphics
subsystem to create an additional thread, which will still run
after the main thread expires. This may also depend on the platform
and the underlying graphics system.
A temporary fix is to add System.exit(0) to the main functions
of applications which use FOP (or Batik). JDK 1.4 was still beta
last time i checked, you may want to try it anyway.

HTH
J.Pietschmann

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]