https://issues.apache.org/bugzilla/show_bug.cgi?id=50471
--- Comment #4 from Andreas L. Delmelle adelme...@apache.org 2011-01-07
07:31:03 EST ---
(In reply to comment #3)
At least there should be some configuration available to the end user to tell
FOP to use some default line break in such
https://issues.apache.org/bugzilla/show_bug.cgi?id=49848
--- Comment #1 from Andreas L. Delmelle adelme...@apache.org 2011-01-07
07:38:42 EST ---
Studying this issue closer, it seems to originate in TextLM, line 708:
...
} else if (inWhitespace) {
On Fri, Jan 07, 2011 at 07:31:07AM -0500, bugzi...@apache.org wrote:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50471
--- Comment #4 from Andreas L. Delmelle adelme...@apache.org 2011-01-07
07:31:03 EST ---
Very right indeed.
So, if no one objects, I will apply the patch as
On 07 Jan 2011, at 14:17, Simon Pepping wrote:
Hi Simon,
On Fri, Jan 07, 2011 at 07:31:07AM -0500, bugzi...@apache.org wrote:
So, if no one objects, I will apply the patch as proposed. FOP will no longer
crash, but simply show a '#' for such unassigned codepoints in the output.
Treating them
I think so. The use of # is mostly historical due to lack of Unicode
support initially. At least I believe so. The first fonts were WinAnsi
only. IMO, it makes sense to make that transition. However, for
single-byte fonts, we might still need to use #. Not sure.
On 07.01.2011 14:17:42 Simon
On Fri, Jan 07, 2011 at 02:38:49PM +0100, Andreas Delmelle wrote:
On 07 Jan 2011, at 14:17, Simon Pepping wrote:
Hi Simon,
On Fri, Jan 07, 2011 at 07:31:07AM -0500, bugzi...@apache.org wrote:
So, if no one objects, I will apply the patch as proposed. FOP will no
longer
crash, but
I've been trying to see if I can modify the source to eliminate the
fonts that come packaged with it. I'm not sure why it needs to include
Courier, Helvetica, etc. I would think they're just a waste of space if
FOP is designed to use custom fonts or installed fonts. I pass in
custom fonts using
On 07.01.2011 15:06:19 Eric Douglas wrote:
I've been trying to see if I can modify the source to eliminate the
fonts that come packaged with it. I'm not sure why it needs to include
Courier, Helvetica, etc.
The PDF specification requires support for the so-called Base 14 fonts.
And so does
On Fri, Jan 07, 2011 at 02:44:13PM +0100, Jeremias Maerki wrote:
I think so. The use of # is mostly historical due to lack of Unicode
support initially. At least I believe so. The first fonts were WinAnsi
only. IMO, it makes sense to make that transition. However, for
single-byte fonts, we
On 07 Jan 2011, at 14:58, Simon Pepping wrote:
snip /
I had not yet thought so far. I reflected on the use of '#' as the
replacement character for missing glyphs. Is that not particular to
FOP, and should we not conform to Unicode and use the Unicode
replacement character in such situations?
That seems odd, to include information for fonts which are never used.
I'll just ignore that then. It just seemed like that would be putting a
lot into the jar which will never be needed. I'm running in webstart,
referencing fop.jar in the jnlp, so anything in the jar has to be copied
to the
https://issues.apache.org/bugzilla/show_bug.cgi?id=43166
Simon Pepping spepp...@apache.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Your patch seems OK to me. Even though the conditionals handle some
tricky navigation through the list, this is the best way to use the
similarities between the two methods.
Will you apply it?
Simon
On Wed, Jan 05, 2011 at 02:01:55PM -0500, bugzi...@apache.org wrote:
https://issues.apache.org/bugzilla/show_bug.cgi?id=49186
--- Comment #2 from Andreas L. Delmelle adelme...@apache.org 2011-01-07
12:18:10 EST ---
Not immediately dismissing this, but it did get me wondering which situation is
wrong.
FOP does not generate an area for empty inlines if they have
On 07 Jan 2011, at 17:03, Simon Pepping wrote:
Your patch seems OK to me. Even though the conditionals handle some
tricky navigation through the list, this is the best way to use the
similarities between the two methods.
Will you apply it?
Sure, will do!
Regards
Andreas
https://issues.apache.org/bugzilla/show_bug.cgi?id=48534
--- Comment #3 from Andreas L. Delmelle adelme...@apache.org 2011-01-07
13:33:50 EST ---
The crash is indeed a bug.
However, I believe it is also erroneous to have the following property
specifications (appearing twice in the sample
I try not to let it do anything by default so I don't have to worry
about anything changing in a future version.
I write programs which create my xml input, I'm not trying to read in
text like a book, so I don't have any linefeeds. All text blocks fit on
one line.
I don't worry about where text
https://issues.apache.org/bugzilla/show_bug.cgi?id=48380
Andreas L. Delmelle adelme...@apache.org changed:
What|Removed |Added
Status|NEW |RESOLVED
On 07 Jan 2011, at 20:13, Eric Douglas wrote:
Hi
snip /
A lot of people put xsl tags in line as you've done there with
white-space-treatment, but I think it's easier to read if you split them
out to their own tags.
Actually, I was just writing plain FO (= what results after applying the
https://issues.apache.org/bugzilla/show_bug.cgi?id=50471
Andreas L. Delmelle adelme...@apache.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Interesting. I write it out neatly in the xsl. I don't normally look
at the fo. I run embedded code where I normally run a transform with an
output result created from the FOP handler so I get out a document and
any fo generated would stay within the transformer. If I run that same
transform
21 matches
Mail list logo
