RE: Line breaks and other typographical stuff (was: Re: Latest FOP schema)

[Arved Sandstrom]

A drop cap, in other words. :-)

> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
> Sent: May 14, 2002 4:47 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Line breaks and other typographical stuff (was: Re: Latest
> FOP schema)
>
>
> Arved Sandstrom wrote:
> > text-indent. If that's not it, what do you mean by indented initial?
>
> I meant what the following HTML snippet shows:
> 
>
>  
> cellspacing="0px" border="0px">
>  L
>
>orem ipsum dolor sit amet. Consectetuer adipiscing elit, sed
>  diam nonummy. Nibh euismod tincidunt ut laoreet dolore magna.
>  Aliquam erat volutpat. Iriure dolor in
>  
>
>  
>
> J.Pietschmann


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

Re: page-number-citation in combination with force-page-count

[Arnd Beißner]

J.Pietschmann wrote:

> Arnd Beißner wrote:
> > I don't see how I could use a page-position="last" property for this, 
> > either.
> This could work if it were implemented in FOP.
>
> > Did I stumble upon a missing feature in XSL:FO,
> Yes. There is no feature to really *count* pages, you can
> only cite page numbers.
>
> Postprocessing with iText or implementing an extension
> element might help.

Thanks, that'd be an extension element for me. If I do it,
I'll report my findings.

Thanks again,

Arnd Beissner
--
Cappelino Informationstechnologie GmbH
Arnd Beißner
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Email: [EMAIL PROTECTED]
Phone: +49-7031-463458
Mobile: +49-173-3016917


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

Re: Line breaks and other typographical stuff (was: Re: Latest FOP schema)

[Patrick Andries]

J.Pietschmann wrote:

> Patrick Andries wrote:
>
>>> This begs the question: how should arbitrary
>>> non-breaking spaces be expressed in XSLFO, and how often does
>>> this issue arise? 
>>
>> Well, in fine French typography, this occurs often. Semicolon, 
>> question marks and exclanation marks, for instance, should be 
>> preceded by a fine non-breaking space while colon and closing 
>> guillemet ( ») should be preceded by a larger non-breaking space. I 
>> believe Unicode does not distinguish between these two cases, its 
>> customary answer would be that this is a higher protocol's duty : 
>> Unicode only marks a semantic function (non-breaking space) not its 
>> appearance. In other words, it's FO's problem ?
>
>
> This is my understanding. There is already a certain proliferation
> of spaces, and the Unicoders quite explicitely stated they feel
> mainly responsible for stuff resulting in glyphs


Well, they feel responsible for characters. Glyphs is not Unicode's 
realm, they will off course turn out as such (most of  them in any case: 
some are invisible, such as language tags).

> and want to
> support control characters, separators and spaces only to the
> extent necessary for compatibility and to deal with the cases
> which arise most often. I think they would like if there were
> a fo:word :-)

Not sure, we actually discussed this topic on the Unicode internal list 
(sentence and word boundaries) . Word is a very language-specific thing: 
even French and English don't use the same typographical conventions to 
delimit them. Never mind languages like Thai where spaces do not 
separate words. Also I do not know off hand of any Unicode rendering 
algorithm that needs to know what a word is (sorting does), determing 
what is a paragraph (), however, is essential for 
bidirectional rendering.

>
> Well, arbitrary spaces can be achived in XSLFO by using space-start
> on a fo:inline. Attaching a keep-with-previous="always" should make
> it non-breaking in my understanding, for example
>  Mr. keep-with-previous="always">Bean
> Seems to be an awful lot to write for a sort of fine tuning effect
> (most readers wouldn't appreciate it, or even take notice).

This insertion should be done at another level (in French the 
non-breaking width variation is pretty deterministic, an XSLT stylesheet 
could do it I suppose).

> Well, current FOP ignores both properties on fo:inline anyway. 

(Already mentioned on an different list : I would really love to have an 
idea how things are progressing. It would be good for this to be posted 
regularly in a succinct fashion on the Web site. 
http://xml.apache.org/fop/design/status.html is very laconic. Difficult 
to plan any action on this base.)

>
>
> Ah, again:
>  Mozilla
> hopefully never breaks in the middle unless permitted by hyphenation,
> it's just a word with a gap. Is this correct? 

Intuitively, yes.

P. Andries

Tout Unicode en français
--- http://hapax.iquebec.com --

>



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

Re: page-number-citation in combination with force-page-count

[J.Pietschmann]

Arnd Beißner wrote:
> I don't see how I could use a page-position="last" property for this, 
> either.
This could work if it were implemented in FOP.

> Did I stumble upon a missing feature in XSL:FO,
Yes. There is no feature to really *count* pages, you can
only cite page numbers.

Postprocessing with iText or implementing an extension
element might help.

J.Pietschmann


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

page-number-citation in combination with force-page-count

[Arnd Beißner]

Question:

In my current print jobs, I have two page sequences where the second 
sequence has its own numbering
scheme (reset to 1). The PDF I generate need be printed in duplex mode. My 
first page sequence
typically has two pages, but there's sometimes a document where the first 
sequence is three pages
long. Since I need to have an even number of pages in the first sequence 
(otherwise duplex printing
is broken, in insert a force-page-count="end-on-even" in the first 
sequence.

Works fine. But: I use page-number-citations in the footer to get "page x 
of y" style page counts.
To get the "y", I append an empty block with an id property to the flow 
that I reference with the
page-number-citation.

Because that empty block happens to be formatted on page 3 (4 is empty in 
this case), I get
a footer "page 4 of 3" on page 4.

Of course, this is logical, I think. Now the question is: how can that 
kind of problem be solved
with :FO (preferably with FOP, too.. 8-) )

I need to reference a formatting object that is on the "empty" page. This 
I cannot do, since I
don't have a formatting object on the page - besides the static-content 
footer which doesn't
help, because it's repeated -.

Well, ok, I might be able to do something with the blank-or-not-blank 
property, but then the
blank page isn't counted.

I don't see how I could use a page-position="last" property for this, 
either.

Did I stumble upon a missing feature in XSL:FO, or am I just too tired?
Any ideas?

Thanks in advance,

Arnd Beissner
--
Cappelino Informationstechnologie GmbH
Arnd Beißner
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Email: [EMAIL PROTECTED]
Phone: +49-7031-463458
Mobile: +49-173-3016917


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

Re: direct rendering of images to pdf

[Paul Reavis]

I've implemented a cache-to-disk mechanism for PDFStream that seems
promising. Unfortunately, I still have to hork up the entire byte
array in order to apply PDFFilters to it. I assume this is related to
how PDF files are compressed. Is there a way to:

a) apply a pdf filter incrementally, rather than all in one go
(e.g. on 1024-byte blocks), OR

b) store the filtered data in more than one chunk

Perhaps I'm wrong about the basic problem. But I am running out of
heap on large plots still; my cache file (what was formerly the
contents of PDFStream._data) runs up to 350K or more before it breaks,
and who knows how many copies of those bytes get passed around...


-- 

Paul Reavis  [EMAIL PROTECTED]
Design Lead
Partner Software, Inc.http://www.partnersoft.com

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

Re: Line breaks and other typographical stuff (was: Re: Latest FOPschema)

[J.Pietschmann]

Patrick Andries wrote:
>>This begs the question: how should arbitrary
>>non-breaking spaces be expressed in XSLFO, and how often does
>>this issue arise? 
> Well, in fine French typography, this occurs often. Semicolon, question 
> marks and exclanation marks, for instance, should be preceded by a fine 
> non-breaking space while colon and closing guillemet ( ») should be 
> preceded by a larger non-breaking space. I believe Unicode does not 
> distinguish between these two cases, its customary answer would be that 
> this is a higher protocol's duty : Unicode only marks a semantic 
> function (non-breaking space) not its appearance. In other words, it's 
> FO's problem ?

This is my understanding. There is already a certain proliferation
of spaces, and the Unicoders quite explicitely stated they feel
mainly responsible for stuff resulting in glyphs and want to
support control characters, separators and spaces only to the
extent necessary for compatibility and to deal with the cases
which arise most often. I think they would like if there were
a fo:word :-)
Well, arbitrary spaces can be achived in XSLFO by using space-start
on a fo:inline. Attaching a keep-with-previous="always" should make
it non-breaking in my understanding, for example
  Mr. Bean
Seems to be an awful lot to write for a sort of fine tuning effect
(most readers wouldn't appreciate it, or even take notice).
Well, current FOP ignores both properties on fo:inline anyway.

Ah, again:
  Mozilla
hopefully never breaks in the middle unless permitted by hyphenation,
it's just a word with a gap. Is this correct?

J.Pietschmann


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

Re: Line breaks and other typographical stuff (was: Re: Latest FOPschema)

[J.Pietschmann]

Arved Sandstrom wrote:
> text-indent. If that's not it, what do you mean by indented initial?

I meant what the following HTML snippet shows:

   
 
   
 L
   
   orem ipsum dolor sit amet. Consectetuer adipiscing elit, sed
 diam nonummy. Nibh euismod tincidunt ut laoreet dolore magna.
 Aliquam erat volutpat. Iriure dolor in
 
   
 

J.Pietschmann


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

Re: Line breaks and other typographical stuff (was: Re: Latest FOP schema)

[Patrick Andries]

Joerg Pietschmann wrote:
[EMAIL PROTECTED]">
  I found them online, the relevant URLs appear to be http://www.unicode.org/Public/UNIDATA/LineBreak.txt http://www.unicode.org/Public/UNIDATA/extracted/DerivedLineBreak.txtand for the interpretation of the codes http://www.unicode.org/Public/UNIDATA/PropertyValueAliases.txt(the lb section)I still think this area is somewhat unintuitive to browse.Does somebody know where there is a more elaborate explanationof the values used there, in particular whether there is aformal description how they are supposed to influence theactual line breaking? I don't want to rely on intuition here,it fails me much to ofte
n...
  
  
http://www.unicode.org/unicode/reports/tr14/ 
  
  [EMAIL PROTECTED]">


  Slightly related question: FOP appears to render the U+00A0 nonbreaking space always at full space width. Shouldn't the spacealso be used for justification purposes? There are, after all,non breaking spaces with a definite width available.
  
  Ooops, major blunder. I should check before posting. Whilethere is a variety of spaces at U+2000 and following codepoints, as well as various additional spaces for some scripts,there is only the common U+00A0 non-breaking space, U+2007figure space (whatever this is)
  
  
Spaces for aligning numbers in a table (also called tabular spaces, at least
in French). These spaces are rather old fashion ones inherited from a Xerox
precursor to Unicode.
Today most spacing is (should) dynamically adjusted in the justifying process
or through tagging for fixed width-ones. Some of these spaces are actual
duplicates of one another (due to a misunderstanding at the normalization
commitees level, U+2000 = U+2002 and U+2001 = U+2003).
  
  
  [EMAIL PROTECTED]">
 and U+202F narrow non-breakingspace available. This begs the question: how should arbitrarynon-breaking spaces be expressed in XSLFO, and how often doesthis issue arise? 


Well, in fine French typography, this occurs often. Semicolon, question marks
and exclanation marks, for instance, should be preceded by a fine non-breaking
space while colon and closing guillemet ( ») should be preceded by a larger
non-breaking space. I believe Unicode does not distinguish between these
two cases, its customary answer would be that this is a higher protocol's
duty : Unicode only marks a semantic function (non-breaking space) not its
appearance. In other words, it's FO's problem ? 

[EMAIL PROTECTED]">
  Well, if we are at this, another typographical nastyness whichcomes to mind is an indented initial. 
  
  
Do you mean a drop cap ? Lettrine in French, Zierbuchstabe oder Spaltenbuchstabe
auf Deutsch ?
  
  
  [EMAIL PROTECTED]">
 This bothers me for quitesome time now: How should this be expressed in XSLFO? In HTML, afloating table around the letter can be used, but  this seemsawkward and does not account for fine tuning like the outdent toaccount for serifs. Also, the automatic displacement of the nextlines could be a problem. I think there is also a float necessaryin XSLFO, perhaps with some adjustments to the width and withrelative positioning for fine tuning.J.Pietschmann



P. Andries

Tout unicode en français
--- http://hapax.iquebec.com-- 
Liste complète des noms de caractères ISO 10646 et Unicode 3.2 mise à jour
Texte complet du standard Unicode annoté.

Re: close the Stream in the CommandLineStarter

[J.Pietschmann]

Juergen Lippold wrote:
> I am trying to include the FOP-Framework into a Java-Environment
 > and to start the conversion inline. But the System.exit exits the
 > whole application. Is there a way to have a java Program starting
 > FOP-Konversion not from the CommandLine?

Yes. Check docs/html-docs/embedding.html and the example code
in docs/examples/embedding/. Search the list archive for
"servlet" or "Driver".

> in the class org.apache.fop.apps.CommandLineStarter there is a 
> System.exit(0) 
> in the run-method, why ?
There were problems with certain JRE and using SVG.

J.Pietschmann


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

Re: Latest FO Schema Improved

[Chuck Paussa]

Oleg,

Oleg Tkachenko wrote:
 > P.S. I believe full-fledged fo schema would be a very useful thing. 
Would you mind if I contribute to this project?
You just did contribute. Thanks. I'll include your change (and any 
others anyone sends me) in the next draft. I'll post it next week to 
give other people time to respond.

I've got nothing in my own FO documents that even come close to 
exercising the full spec. If we want to develop a full-fledged and 
validated schema, I'll need contributions from people who have a real 
need to validate complex documents.

Chuck

Oleg Tkachenko wrote:
 > Hello!
 >
 > Chuck Paussa wrote:
 > I've improved the FO schema adding much better type patterns and 
adding a bunch of attributes that I'd missed the first time around.
 >
 > Well done! I tried to validate my fo documents and the first 
validation error I got was about  content - I have some 
meta info there in my namespace. Spec says:
 > ---
 > Contents:
 > (color-profile)+
 >
 > The fo:declarations flow object may have additional child elements in 
a non-XSL namespace. Their presence
 > does not, however, change the semantics of the XSL namespace objects 
and properties. The permitted
 > structure of these non-XSL namespace elements is defined for their 
namespace(s).
 > 
 >
 > So, I suppose, schema declaration for the element should be as follows:
 >
 > 
 > 
 >   
 > 
 > 
 >
 >   
 > 
 >   
 >
 > btw, this declaration assumes that all  elements 
must come before other stuff, which is not required by spec, but I 
cannot see any way to express such constraints in schema, one could use 
 instead of , but this way we lose control over 
(color-profile)+ constraint.




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

Re: Line breaks and other typographical stuff (was: Re: Latest FOPschema)

[J.Pietschmann]

Arved Sandstrom wrote:
> This would not be covered in UTR 14, Line Breaking Properties?
> (http://www.unicode.org/unicode/reports/tr14/).
> 

Thanks, that's what I was looking for. It's even mentioned
in the data file I looked at...

J.Pietschmann


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

RE: direct rendering of images to pdf

[Jim Urban]

This sounds like something we could really use. Please continue to develop
this and by all means, get it added to the base.

Thanks,

Jim Urban - [EMAIL PROTECTED]
Park City Solutions Inc.
Clinical Connectivity Suite Product Manager
Suite 295
500 Park Blvd.
Itasca, IL  60143
Voice:  (630) 250-3045 x106
Fax:  (630) 250-3046

CONFIDENTIALITY NOTICE
This message and any included attachments are from Park City Solutions Inc.
and are intended only for the entity to which it is addressed. The contained
information is confidential and privileged material. If you are not the
intended recipient, you are hereby notified that any use, dissemination, or
copying of this communication is strictly prohibited and may be unlawful. If
you have received this communication in error please notify the sender of
the delivery error by e-mail or call Park City Solutions Inc. corporate
offices at (435) 654-0621

-Original Message-
From: Paul Reavis [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Reavis
Sent: Tuesday, May 14, 2002 1:38 PM
To: [EMAIL PROTECTED]
Subject: direct rendering of images to pdf

I have finished the initial implementation of what I call on-the-fly
images in fop. Essentially this is a callback system that has an
object draw itself into a PDFGraphics2D during pdf rendering, rather
than going through intermediate steps such as svg or Images.

I'm fairly pleased with it, though it did turn up some other
scalability problems.

Initially, plotting one test map took 1.25 minutes; the new version
takes about 8 seconds. The original implementation, using the standard
fop distribution generated an svg
(slow), then loaded the svg (slow), then rendered the svg to the
pdf. The new implementation registers some callbacks for the included
images, and the callbacks render directly.

Memory usage is much better now, as well. We frequently overran the
default 64MB with the original implementation, since the dom-based svg
generation and reloading both ate up the heap. Now I can generally
plot up to E size PDFs (34" x 44"), though for complex maps I still
run out of heap.

Looking into the implementation of PDFRenderer and PDFGraphics2D, it
looks like the memory bottleneck with the new implementation is
probably the fact that
PDFGraphics2D stores its results in a StringWriter, and then that
StringWriter is appended to the PDFStream's own
ByteArrayOutputStream. This requires twice as much ram as simply
writing directly to the PDFStream.

True scalability, frankly, will require rendering directly to a file,
and keeping as little in RAM as possible. I didn't chase the code to
see how difficult that would be, but I figure it's not trivial. The
benefits would be enormous - for example, I could plot an entire
multi-hundred page map book.

On the other hand, the ability to have PDFGraphics2D write directly to
the PDFStream should be fairly easy to implement. I'm looking into this
now.

I did also uncover some bugs. Most prominently, PDFGraphics2D
instances spawned from others using createGraphics have their own
StringWriters and therefore anything rendered to them kind of
disappears off into space. I rewrote it so they share the same
StringWriter.

In any case, I have a few major changes that may be useful. Are they,
and if so should I go ahead and see about getting CVS write access, or
does someone want to "sponsor" me or should I simply send a patch? I
have a feeling I'll be returning to the code in the future in any
case.

Thanks. While I'm finding fop to be kind of a bear, it's still the
only real game in town for what I'm trying to do, and I'm getting some
great results - we just plotted half the state of new hampshire onto
a page the size of a bedsheet, and that's not easy to do without
banging your own postscript - add to that the ability to stick these
plots on nicely-formatted reports with all the power of FO too and it
makes my life a lot easier.

--

Paul Reavis  [EMAIL PROTECTED]
Design Lead
Partner Software, Inc.http://www.partnersoft.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]

direct rendering of images to pdf

[Paul Reavis]

I have finished the initial implementation of what I call on-the-fly
images in fop. Essentially this is a callback system that has an
object draw itself into a PDFGraphics2D during pdf rendering, rather
than going through intermediate steps such as svg or Images. 

I'm fairly pleased with it, though it did turn up some other
scalability problems.

Initially, plotting one test map took 1.25 minutes; the new version
takes about 8 seconds. The original implementation, using the standard
fop distribution generated an svg
(slow), then loaded the svg (slow), then rendered the svg to the
pdf. The new implementation registers some callbacks for the included
images, and the callbacks render directly.

Memory usage is much better now, as well. We frequently overran the
default 64MB with the original implementation, since the dom-based svg
generation and reloading both ate up the heap. Now I can generally
plot up to E size PDFs (34" x 44"), though for complex maps I still
run out of heap.

Looking into the implementation of PDFRenderer and PDFGraphics2D, it
looks like the memory bottleneck with the new implementation is
probably the fact that 
PDFGraphics2D stores its results in a StringWriter, and then that
StringWriter is appended to the PDFStream's own
ByteArrayOutputStream. This requires twice as much ram as simply
writing directly to the PDFStream.

True scalability, frankly, will require rendering directly to a file,
and keeping as little in RAM as possible. I didn't chase the code to
see how difficult that would be, but I figure it's not trivial. The
benefits would be enormous - for example, I could plot an entire
multi-hundred page map book.

On the other hand, the ability to have PDFGraphics2D write directly to
the PDFStream should be fairly easy to implement. I'm looking into this
now. 

I did also uncover some bugs. Most prominently, PDFGraphics2D
instances spawned from others using createGraphics have their own
StringWriters and therefore anything rendered to them kind of
disappears off into space. I rewrote it so they share the same
StringWriter.

In any case, I have a few major changes that may be useful. Are they,
and if so should I go ahead and see about getting CVS write access, or
does someone want to "sponsor" me or should I simply send a patch? I
have a feeling I'll be returning to the code in the future in any
case.

Thanks. While I'm finding fop to be kind of a bear, it's still the
only real game in town for what I'm trying to do, and I'm getting some
great results - we just plotted half the state of new hampshire onto
a page the size of a bedsheet, and that's not easy to do without
banging your own postscript - add to that the ability to stick these
plots on nicely-formatted reports with all the power of FO too and it
makes my life a lot easier.

-- 

Paul Reavis  [EMAIL PROTECTED]
Design Lead
Partner Software, Inc.http://www.partnersoft.com

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

Latest FO Schema Improved

[Chuck Paussa]

I've improved the FO schema adding much better type patterns and adding 
a bunch of attributes that I'd missed the first time around.

Chuck Paussa




fop4e.zip
Description: Zip compressed data

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

Re: Error when reading EPS images

[claes . bergsten]

Ignore the System.out.println statements...

// Claes



|-+>
| |   claes.bergsten@tj|
| |   group.com|
| ||
| |   14.05.2002 17:40 |
| |   Please respond to|
| |   fop-dev  |
| ||
|-+>
  
>--|
  |
  |
  |   To:   [EMAIL PROTECTED] 
  |
  |   cc:   (bcc: Claes Bergsten/NO/TJG)   
  |
  |   Subject:  Error when reading EPS images  
  |
  
>--|




Hi,

I found an error when fop proceses EPS images with negative numbers in
BoundingBox.

It only checks for ASCII codes between 48 and 57 and therefor quits
immediately when
the first char is '-'.

I changed the line (marked in the code snippet below) from:

while (nidx < epsFile.length && (epsFile[nidx] >= 48 && epsFile[nidx] <=
57))
to:
while (nidx < epsFile.length && ((epsFile[nidx] >= 48 && epsFile[nidx] <=
57)||epsFile[nidx] == 45))

This solves the problem I encountered.
Since I have not performed updates before I figured it would be quicker if
anyone with experience made the change for me.

Would tyake the oppurtunity to thank you for a good product and good
support. :-)

Package: org.apache.fop.image.analyser
File: EPSReader.java
...
private int readLongString(long[] mbbox, int i, int idx) {
while (idx < epsFile.length && (epsFile[idx] == 32))
   idx++;

int nidx = idx;

->  while (nidx < epsFile.length && ((epsFile[nidx] >= 48 &&
epsFile[nidx] <= 57)||epsFile[nidx] == 45))
nidx++;

System.out.println( "Idx: " + idx + " Nidx: " + nidx);

byte[] num = new byte[nidx - idx];
System.arraycopy(epsFile, idx, num, 0, nidx-idx);
String ns = new String(num);

System.out.println( "Stringnumber: " + ns);

mbbox[i] = Long.parseLong(ns);

return (1+nidx - idx);
}
...

cheers

---
Claes Bergsten
Software Development Engineer
TJ Group as

--Contact
[EMAIL PROTECTED]
+47 91668984
www.tjgroup.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]

Error when reading EPS images

[claes . bergsten]

Hi,

I found an error when fop proceses EPS images with negative numbers in
BoundingBox.

It only checks for ASCII codes between 48 and 57 and therefor quits
immediately when
the first char is '-'.

I changed the line (marked in the code snippet below) from:

while (nidx < epsFile.length && (epsFile[nidx] >= 48 && epsFile[nidx] <=
57))
to:
while (nidx < epsFile.length && ((epsFile[nidx] >= 48 && epsFile[nidx] <=
57)||epsFile[nidx] == 45))

This solves the problem I encountered.
Since I have not performed updates before I figured it would be quicker if
anyone with experience made the change for me.

Would tyake the oppurtunity to thank you for a good product and good
support. :-)

Package: org.apache.fop.image.analyser
File: EPSReader.java
...
private int readLongString(long[] mbbox, int i, int idx) {
while (idx < epsFile.length && (epsFile[idx] == 32))
   idx++;

int nidx = idx;

->  while (nidx < epsFile.length && ((epsFile[nidx] >= 48 &&
epsFile[nidx] <= 57)||epsFile[nidx] == 45))
nidx++;

System.out.println( "Idx: " + idx + " Nidx: " + nidx);

byte[] num = new byte[nidx - idx];
System.arraycopy(epsFile, idx, num, 0, nidx-idx);
String ns = new String(num);

System.out.println( "Stringnumber: " + ns);

mbbox[i] = Long.parseLong(ns);

return (1+nidx - idx);
}
...

cheers

---
Claes Bergsten
Software Development Engineer
TJ Group as

--Contact
[EMAIL PROTECTED]
+47 91668984
www.tjgroup.com



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

DO NOT REPLY [Bug 4337] - TIFF image is not working with fop

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

TIFF image is not working with fop

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-05-14 14:00 ---
FOP 0.20.3 uses the Jimi image library to process TIFF images. The library
itself is not distributed with FOP, you have to get it yourself and perhaps
rebuild FOP from the source, refer to the documentation delivered with FOP.
There is no guarantee that Jimi supports the TIFF subformat you are using,
refer to the Jimi docs.
Alternatively, FOP can take advantage of any JAI conformant library, you can
try and get such a library capable of processing TIFF images.
Apart from this, "not working" is a bit slim for a bug report.

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

RE: close the Stream in the CommandLineStarter

[Rhett Aultman]

CommandLineStarter is, if I'm not mistaken, part of the FOP standalone program, so 
you're not supposed to use it to embed FOP in your applications.  There are 
instructions on how to embed FOP on the FOP website, so you should check those.  If 
launching FOP via its standalone command line implementation is the only way you can 
do it, you need to have your runtime spawn it as an external process via one of the 
Runtime.exec() methods.

-Original Message-
From: Juergen Lippold [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 14, 2002 9:45 AM
To: <
Subject: close the Stream in the CommandLineStarter


Hello, 

I am trying to include the FOP-Framework into a Java-Environment and to start the 
conversion inline. But the System.exit exits the whole application. Is there a way to 
have a java Program starting FOP-Konversion not from the CommandLine?


in the class org.apache.fop.apps.CommandLineStarter there is a 
System.exit(0) 
in the run-method, why ?
Is it a problem to add a FileOutputStream and to close the stream in the finally 
method instead of using the exit?

Thanks for help 
Juergen Lippold


public void run() throws FOPException {
String version = Version.getVersion();

log.info(version);

XMLReader parser = inputHandler.getParser();
setParserFeatures(parser);

Driver driver = new Driver();
driver.setLogger(log);
driver.setBufferFile(commandLineOptions.getBufferFile());

if (errorDump) {
driver.setErrorDump(true);
}

FileOutputStream fos = null;

try {
driver.setRenderer(commandLineOptions.getRenderer());
//driver.setOutputStream( new FileOutputStream(
//  commandLineOptions.getOutputFile()));
fos = new FileOutputStream(commandLineOptions.getOutputFile());
driver.setOutputStream(fos);
driver.getRenderer().setOptions(
  commandLineOptions.getRendererOptions());
driver.render(parser, inputHandler.getInputSource());
//
//System.exit(0);   Do not stop here in the finally part the file will be 
closed
   //
} catch (Exception e) {
if (e instanceof FOPException) {
throw (FOPException) e;
}
throw new FOPException(e);
}
finally {
  try {
if (fos != null) fos.close(); // closing the stream
  }
  catch (IOException e) {
throw new FOPException(e);
  }  
}
}


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


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

close the Stream in the CommandLineStarter

[Juergen Lippold]

Hello, 

I am trying to include the FOP-Framework into a Java-Environment and to start the 
conversion inline. But the System.exit exits the whole application. Is there a way to 
have a java Program starting FOP-Konversion not from the CommandLine?


in the class org.apache.fop.apps.CommandLineStarter there is a 
System.exit(0) 
in the run-method, why ?
Is it a problem to add a FileOutputStream and to close the stream in the finally 
method instead of using the exit?

Thanks for help 
Juergen Lippold


public void run() throws FOPException {
String version = Version.getVersion();

log.info(version);

XMLReader parser = inputHandler.getParser();
setParserFeatures(parser);

Driver driver = new Driver();
driver.setLogger(log);
driver.setBufferFile(commandLineOptions.getBufferFile());

if (errorDump) {
driver.setErrorDump(true);
}

FileOutputStream fos = null;

try {
driver.setRenderer(commandLineOptions.getRenderer());
//driver.setOutputStream( new FileOutputStream(
//  commandLineOptions.getOutputFile()));
fos = new FileOutputStream(commandLineOptions.getOutputFile());
driver.setOutputStream(fos);
driver.getRenderer().setOptions(
  commandLineOptions.getRendererOptions());
driver.render(parser, inputHandler.getInputSource());
//
//System.exit(0);   Do not stop here in the finally part the file will be 
closed
   //
} catch (Exception e) {
if (e instanceof FOPException) {
throw (FOPException) e;
}
throw new FOPException(e);
}
finally {
  try {
if (fos != null) fos.close(); // closing the stream
  }
  catch (IOException e) {
throw new FOPException(e);
  }  
}
}


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

Re: a very humble request

[fred redf]

Hi Keiron and All,

Thanks for your response. I changed my way to another
solution involving a little java class wrapping
jeuclid's MathTransformer that i call thru my xsl
stylesheet with xalan java extension mechanism that
generates svg code directly inside fo code.
I seems to be ok.
Bye,
Fred.



--- Keiron Liddle <[EMAIL PROTECTED]> a écrit : > Hi
Fred,
> 
> The extension that does the mml stuff is only in the
> development cvs. It
> is not part of (and won't work with) the maintain
> branch which is what
> you will need to use.
> Sorry can't be of more help.
> 
> Also you would need to compile the extension and
> place the jar in the
> classpath to get it to work.
> 
> Keiron.
> 
> On Mon, 2002-05-13 at 17:37, fred redf wrote:
> > Hi all,
> > I'm currently working on pdf generation of
> (mostly)
> > text, and (*a few*) equations. I usually wait for
> > maintenance releases of fop, but this time, we
> really
> > need jeuclid's extension. I've downloaded last cvs
> > generated .tar.gz (xml-fop_20020513103339.tar.gz)
> > compiled it (no prob). I got jeuclid source and
> > compiled them (no prob). But i'm not able to run
> the
> > fo+mml examples to pdf.
> > Am I doing something wrong?
> > Thanks a zillion times for your attention.
> > Fred.
> 
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, email:
> [EMAIL PROTECTED]
>  

___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

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

pdf generation of absolute block-container

[Enrico Horn]

Hi,
I have a problem with FOP-0.20.3 and way its generating
the pdf output of absolut positioned block-containers.
Here is my problem:
(Text has been modified to protect the innocent)
I define block containers in a page-sequence like this:


some text




some more text




even more text



As you can see all of the block containers share the same height,width and 
top.the only difference is the
positioning for left.
Now that is what Fop generates in the pdf:
/F1 8 Tf
0.0 Tc
1 0 0 1 141.731 268.217 Tm [(some text) 0.0 Tc
 
Definition of the Text Matrix
-11437.625 (some more text) 0.0 Tc
^ 
relative positioning
-11326.5 (even more text) ] TJ

As you can see only the first block is positioned absolut(it has a text 
matrix defined) all
others are defined relative to the first one which is exactly what i dont 
want(besides all those line break
that seem to blow up the size of the file).

My question:
Any way to change that so that all blocks are generated absolut?

Thanks for your help
It is very appreciated in this matter.
Enrico Horn
[EMAIL PROTECTED]

P.S.Please dont ask why I need this behaviour, I need it and would expect 
it from the way
I define my xsf-fo.


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

RE: Line breaks and other typographical stuff (was: Re: Latest FOP schema)

[Arved Sandstrom]

> -Original Message-
> From: Joerg Pietschmann [mailto:[EMAIL PROTECTED]]
> Sent: May 14, 2002 7:52 AM
> To: FOP Dev
> Subject: Line breaks and other typographical stuff (was: Re: Latest FOP
> schema)
> 
> Well, if we are at this, another typographical nastyness which
> comes to mind is an indented initial. This bothers me for quite
> some time now: How should this be expressed in XSLFO? In HTML, a
> floating table around the letter can be used, but  this seems
> awkward and does not account for fine tuning like the outdent to
> account for serifs. Also, the automatic displacement of the next
> lines could be a problem. I think there is also a float necessary
> in XSLFO, perhaps with some adjustments to the width and with
> relative positioning for fine tuning.

text-indent. If that's not it, what do you mean by indented initial?

Regards,
Arved


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

RE: Line breaks and other typographical stuff (was: Re: Latest FOP schema)

[Arved Sandstrom]

> -Original Message-
> From: Joerg Pietschmann [mailto:[EMAIL PROTECTED]]
> Sent: May 14, 2002 7:52 AM
> To: FOP Dev
> Subject: Line breaks and other typographical stuff (was: Re: Latest FOP
> schema)
>
> I found them online, the relevant URLs appear to be
>  http://www.unicode.org/Public/UNIDATA/LineBreak.txt
>  http://www.unicode.org/Public/UNIDATA/extracted/DerivedLineBreak.txt
> and for the interpretation of the codes
>  http://www.unicode.org/Public/UNIDATA/PropertyValueAliases.txt
> (the lb section)
> I still think this area is somewhat unintuitive to browse.
> Does somebody know where there is a more elaborate explanation
> of the values used there, in particular whether there is a
> formal description how they are supposed to influence the
> actual line breaking? I don't want to rely on intuition here,
> it fails me much to often...

This would not be covered in UTR 14, Line Breaking Properties?
(http://www.unicode.org/unicode/reports/tr14/).

Arved


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

Line breaks and other typographical stuff (was: Re: Latest FOP schema)

[Joerg Pietschmann]

Self-followup:

> Peter B. West wrote:
> > These cover such categories as
> > Case, Numeric Value, Dashes, Line Breaking and Spaces.

I found them online, the relevant URLs appear to be
 http://www.unicode.org/Public/UNIDATA/LineBreak.txt
 http://www.unicode.org/Public/UNIDATA/extracted/DerivedLineBreak.txt
and for the interpretation of the codes
 http://www.unicode.org/Public/UNIDATA/PropertyValueAliases.txt
(the lb section)
I still think this area is somewhat unintuitive to browse.
Does somebody know where there is a more elaborate explanation
of the values used there, in particular whether there is a
formal description how they are supposed to influence the
actual line breaking? I don't want to rely on intuition here,
it fails me much to often...

> Slightly related question: FOP appears to render the U+00A0 non
> breaking space always at full space width. Shouldn't the space
> also be used for justification purposes? There are, after all,
> non breaking spaces with a definite width available.

Ooops, major blunder. I should check before posting. While
there is a variety of spaces at U+2000 and following code
points, as well as various additional spaces for some scripts,
there is only the common U+00A0 non-breaking space, U+2007
figure space (whatever this is) and U+202F narrow non-breaking
space available. This begs the question: how should arbitrary
non-breaking spaces be expressed in XSLFO, and how often does
this issue arise? I vaguely remember that the most often arising
use case in common engliish was the space after an abbreviated
title, and this is only available for space justification at the
same level of fine tuning as character spacing (and it should be
a slightly less wide than a full width space).

Well, if we are at this, another typographical nastyness which
comes to mind is an indented initial. This bothers me for quite
some time now: How should this be expressed in XSLFO? In HTML, a
floating table around the letter can be used, but  this seems
awkward and does not account for fine tuning like the outdent to
account for serifs. Also, the automatic displacement of the next
lines could be a problem. I think there is also a float necessary
in XSLFO, perhaps with some adjustments to the width and with
relative positioning for fine tuning.

J.Pietschmann

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

DO NOT REPLY [Bug 9063] - Fop should use org.apache.avalon.framework.logger.Logger

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

Fop should use org.apache.avalon.framework.logger.Logger

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2002-05-14 09:52 ---
This is due to the difference between the latest release and the documentation 
on xml.apache.org which is already updated to reflect the next upcoming 
maintenance release. If you want to use Avalon Logger now, you should download 
FOP from CVS. The current release still relies on Jakarta LogKit. The 
documentation for the current release can be found in the docs subdirectory in 
the distribution.

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

DO NOT REPLY [Bug 9063] New: - Fop should use org.apache.avalon.framework.logger.Logger

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

Fop should use org.apache.avalon.framework.logger.Logger

   Summary: Fop should use org.apache.avalon.framework.logger.Logger
   Product: Fop
   Version: 0.20.3
  Platform: PC
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Documentation states that org.apache.fop.apps.Driver.setLogger accepts 
org.apache.avalon.framework.logger.Logger, but the actual parameter type is 
org.apache.log.Logger. This is a class, not an interface, and Avalon log 
wrappers do not extend it. This makes sharing an existing system logger with 
Fop virtually impossible.

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

Re: Image in PDF contains elements of other image

[Keiron Liddle]

Hi Matthias,

Since the 2 svg sources are effectively two different svg documents as
far as xml and batik are concerned then you cannot reference elements as
if they are in the same document (ie. "#myElement").
You would need a full url that points to the other svg document which as
faar as I know is not possible.
The easiest thing would be to put your common elements into an external
svg file and reference them using the url to that file.

Keiron.

On Tue, 2002-05-14 at 09:02, Matthias wrote:
> Hi
> 
> I am trying to create a PDF document with
> FOP and it contains 2 images which are
> rendered from SVG source by means of the
> '' tag. Now I
> see that only the first image is rendered
> correctly and the 2nd does contain elements
> of the first. Now this is not a problem in
> the SVG source as far as i can tell. Has anybody
> encountered a similar problem?
> 
> Any help much appreciated!
> 
> Regards Matthias
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 
> 



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