[
https://issues.apache.org/jira/browse/FOP-2463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14495970#comment-14495970
]
Manuel Mall commented on FOP-2463:
--
For FOP usage questions like this please don't open
Fop has some generated source files which the ant build creates.
Run your ant build first then add the generated sources (build/gensrc) to
NetBeans as a second source directory. See also
http://wiki.apache.org/xmlgraphics-fop/FOPIDESetupGuide.
Manuel
-Original Message-
From:
Did you to as the wiki suggests under 'Download the project files' a manual
checkout using the svn command line client first followed by a command line
ant build before setting up the project in NetBeans?
Manuel
-Original Message-
From: bonekrusher [mailto:[EMAIL PROTECTED]
Sent:
files are generated
using fop custom tools which are not available through the NetBeans build
process.
Manuel
-Original Message-
From: Manuel Mall [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 20 May 2008 8:56 PM
To: 'fop-dev@xmlgraphics.apache.org'
Subject: RE: Setting up FOP Trunk
Vincent,
Just a quick question coming from someone who has absolutely no clue about
what you are really doing and just based on the commit comment.
We have been 'bitten' before by moving things into the fo tree only to find
out that it doesn't work when it comes to fo:markers as they inherit the
On Tuesday 27 November 2007 19:10, Jeremias Maerki wrote:
Dear Foppies,
deleted most of the post - read the original /
If I would be the responsible project manager who is tasked with getting
a FOP 1.0 release out with the feature set as described on the wiki I
would certainly strongly resist
Because the issue of font selection by character was raised again on
fop-user I have started to look at it as the appropriate font data
structures are now in place.
I am just looking for a confirmation here of the selection algorithm. My
understanding is that for each character, independent of
-Original Message-
From: Chris Bowditch [mailto:[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Author: jeremias
Date: Tue Oct 16 08:12:45 2007
New Revision: 585167
URL: http://svn.apache.org/viewvc?rev=585167view=rev
Log:
Bugfix: If auto-detection is enabled,
On Wednesday 08 August 2007 04:02, Andreas L Delmelle wrote:
On Aug 4, 2007, at 13:22, Vincent Hennebert wrote:
Manuel Mall a écrit :
snip/
I have been following this discussion with very little attempt to
understand the intricate technical details of concurrent maps etc,
but
I am
On Friday 03 August 2007 07:01, Andreas L Delmelle wrote:
On Aug 1, 2007, at 10:06, Manuel Mall wrote:
On Wednesday 01 August 2007 15:45,
[EMAIL PROTECTED]
What am I missing?
You are not missing anything, AFAICT except that:
... FOP still aims for 1.4 compliance
On Wednesday 01 August 2007 15:45, [EMAIL PROTECTED]
wrote:
Andreas L Delmelle writes:
snip/
I've been playing with trying to make the cache thread-local
If in doubt, you could always make the caching multi-level.
L1 is the current global cache. L2 is a thread-local equivalent
of the same
On Tuesday 31 July 2007 20:48, Vincent Hennebert wrote:
Hi,
There have been various questions on fop-user recently regarding the
RTF output of FOP. Personally I’m incapable of helping in this area,
and also most unwilling to.
Tell me if I’m wrong, but I suspect that in the current team
On Thursday 19 July 2007 07:28, Andreas L Delmelle wrote:
On Jul 19, 2007, at 01:10, Andreas L Delmelle wrote:
snip /
BTW: the following is perfectly legitimate
Object o = new Object();
Just wondering if anyone can think of a use-case...
If you want a class internal object to synchronize
On Thursday 26 July 2007 00:23, Andreas L Delmelle wrote:
On Jul 25, 2007, at 02:25, Manuel Mall wrote:
On Wednesday 25 July 2007 05:17, Andreas L Delmelle wrote:
Anyone have any objections, for instance, to change the default
behaviour of FontInfo.fontLookup(String[], ...) to something
On Wednesday 25 July 2007 05:17, Andreas L Delmelle wrote:
On Jul 21, 2007, at 14:07, Andreas L Delmelle wrote:
snip /
As to then further addressing the font-family fallback/font-
selection issue, ...
snip /
Change the getFontState() signature:
- either make it
public Font[]
On Sunday 22 July 2007 00:45, Vincent Hennebert wrote:
Hi Manuel,
Author: manuel
Date: Wed Jul 18 03:40:12 2007
New Revision: 557219
URL: http://svn.apache.org/viewvc?view=revrev=557219
Log:
Fixed incomplete support for Unicode word joiners
Can you please have a look at the
On Thursday 19 July 2007 19:27, Andreas L Delmelle wrote:
On Jul 19, 2007, at 04:06, Manuel Mall wrote:
snip /
Sorry Andreas but I still don't get it. We have this test case
fo:blockThis is fo:inline keep-together.within-
line=alwaysBlah blah blah blah!/fo:inline/fo:block
OK
On Thursday 19 July 2007 19:49, Andreas L Delmelle wrote:
On Jul 19, 2007, at 13:34, Manuel Mall wrote:
On Thursday 19 July 2007 19:27, Andreas L Delmelle wrote:
On Jul 19, 2007, at 04:06, Manuel Mall wrote:
snip /
Sorry Andreas but I still don't get it. We have this test case
On Wednesday 18 July 2007 23:15, Manuel Mall wrote:
On Wednesday 18 July 2007 19:01, Andreas L Delmelle wrote:
On Jul 18, 2007, at 10:15, Vincent Hennebert wrote:
J.Pietschmann a écrit :
Brad Smith wrote:
snip/
Turned out adding basic support for
keep-together.within-line=always
On Thursday 19 July 2007 02:31, Andreas L Delmelle wrote:
On Jul 18, 2007, at 20:06, [EMAIL PROTECTED] wrote:
Hi Manuel others
Author: manuel
Date: Wed Jul 18 11:06:09 2007
New Revision: 557347
URL: http://svn.apache.org/viewvc?view=revrev=557347
Log:
Added support for
On Thursday 19 July 2007 08:39, Andreas L Delmelle wrote:
On Jul 19, 2007, at 01:31, Manuel Mall wrote:
snip /
I don't quite understand what you are trying to say here. The test
case
in question checks the use of keep-together.within-line=always in
the
context of fo:block, fo:inline
On Wednesday 18 July 2007 02:58, Andreas L Delmelle wrote:
On Jul 16, 2007, at 22:25, J.Pietschmann wrote:
Vincent Hennebert wrote:
Addition of a general-purpose int-to-int map ...
...
As to the efficiency:
I did some measurements of the difference in processing speed (for
64K
On Saturday 14 July 2007 23:37, Jess Holle wrote:
Andreas L Delmelle wrote:
On Jul 13, 2007, at 21:16, Andreas L Delmelle wrote:
On Jul 13, 2007, at 15:45, Vincent Hennebert wrote:
snip /
As always, we value your input and feedback.
So I suppose auto table-layout is still out of the
On Saturday 30 June 2007 03:00, Apache Wiki wrote:
+ === Alternative Implementation ===
+
+ Rationale
+
+ Given the above noted dependencies, there seems to be a third
alternative: create multiple FOText instances in the FOTree, which
would lead to two separate TextLMs being
On Tuesday 20 March 2007 04:10, Andreas L Delmelle wrote:
Begin forwarded message:
From: Andreas L Delmelle [EMAIL PROTECTED]
snip/
fo:block margin-left=0pt margin-right=0pt unicode-
bidi=embed
fo:block-container absolute-position=absolute
left=16.0% top=16.0%
On Tuesday 13 March 2007 17:50, Vincent Hennebert wrote:
[Moving to fop-dev as we're going to speak about implementation
details]
Andrejus Chaliapinas a écrit :
Hi Jeremias,
I've just checked since I was curious. It's already in 0.90. Seems
to have to do with font metrics. Take a look
Jay,
I am confused by this and your following check-in.
These look like SVN control files and not actual sources.
Manuel
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 7 March 2007 02:18
To: fop-commits@xmlgraphics.apache.org
Subject: svn commit:
On Wednesday 24 January 2007 09:11, The Web Maestro wrote:
I'd like to propose Jay as an XML Graphics committer (FOP working
set). I believe he will be a solid addition to our work force.
+1 from me too.
Regards,
The Web Maestro
Manuel
On Monday 15 January 2007 07:05, J.Pietschmann wrote:
Manuel Mall wrote:
2. Unicode text boundaries (UAX#29) especially word boundaries. Do
we need this? It does not determine the word breaks to which the
word spacing property is applied to as this is determined by the
treat-as-word-space
Just committed the initial support for the soft hyphen.
As we had two in favour of having the SHY always produce a break
opportunity and only one against that's the route I took.
I had no luck with giving the SHY a reduced penalty and have the Knuth
algorithm favour them before normal
On Saturday 13 January 2007 19:57, Vincent Hennebert wrote:
Jeremias Maerki a écrit :
On 12.01.2007 09:25:59 Vincent Hennebert wrote:
Jeremias Maerki a écrit :
Good to see that happen! Here's my take:
On 11.01.2007 13:24:16 Manuel Mall wrote:
Hi,
snip/
Still don't agree. Overriding
After having delved into the UAX#14 and SHY issues I am interested in
compiling a FOP UNICODE issues list. That is a list of things that
still require work to make FOP Unicode compliant. Obviously the best
place for such a list is the wiki. But before doing this I am
interested in some even
On Friday 12 January 2007 17:25, Vincent Hennebert wrote:
Jeremias Maerki a écrit :
Good to see that happen! Here's my take:
On 11.01.2007 13:24:16 Manuel Mall wrote:
Hi,
when I implemented the UAX#14 line breaking I noticed that fop
doesn't currently support the Unicode soft hyphen
While looking into the support for the Soft Hyphen the area of
hyphenation combined with kerning is causing me trouble.
Aside 1: our fonts page claims we don't support kerning but I believe we
do.
Aside 2: Our tests are based on setting the base14kerning flag. I don't
think this flag is
Hi,
when I implemented the UAX#14 line breaking I noticed that fop doesn't
currently support the Unicode soft hyphen (SHY).
I am thinking of adding support for this character to the line breaking
but am unsure of its correct behaviour in an XSL:FO environment. So I
have few questions related
I am trying to understand the differences between the two
line-stacking-strategies max-height and line-height. As usual the
spec is hard to read / understand.
My understanding of the difference between the two strategies seems to
boil down to: max-height treats the half-leading as space-before
On Tuesday 09 January 2007 18:13, [EMAIL PROTECTED]
wrote:
Andreas L Delmelle writes:
If I remember correctly, that was precisely the problem, since
Cliff's report consists of one giant table. It's supposed to look
like one uninterrupted flow, so figuring out where the
page-sequences
-cases however, the
current implementation is fine IMO.
Isn't our current compliance stated with respect to 1.0 and not 1.1? We
still should revise the text on the page I guess.
On 08.01.2007 05:03:32 Manuel Mall wrote:
On the compliance page it indicates 'partial' for block-container
On Sunday 07 January 2007 23:04, J.Pietschmann wrote:
Manuel Mall wrote:
I was just looking at some inline handling stuff and came across
the inheritance behaviour of the text-decoration property.
IIRC one of the problems is merging the various decoration values:
fo:wrapper text
On Saturday 30 December 2006 21:50, J.Pietschmann wrote:
Manuel Mall wrote:
Probably
should do hyphenation at the same time as it iterates over Knuth
elements in the LineLM and looks pretty 'ugly' as it modifies the
Knuth elements retrospectively.
I'm not sure this will pay off. One
On the compliance page it indicates 'partial' for block-container in the
0.93 column but in the comments it says '[0.93] No known
restrictions.'.
Sounds a bit like a contradiction to me. What should it be?
Manuel
On Thursday 04 January 2007 07:25, Simon Pepping wrote:
I have again prepared the release files for the FOP 0.93 release.
They were created from the tag
https://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-0_93. You
can find them at http://people.apache.org/~spepping/. They are signed
On Thursday 28 December 2006 17:21, [EMAIL PROTECTED] wrote:
- Oorspronkelijk bericht -
Van: J.Pietschmann [mailto:[EMAIL PROTECTED]
Andreas L Delmelle wrote:
Maybe there's a possibility to re-use the existing CharIterators
in the fo package?
I'd think so.
The problem Manuel
Just committed the UAX#14 changes. The commit looks much bigger than it
really is because of the restructure of the codegen directories.
One point to note - There is one file without a license header:
src/codegen/unicode/data/LineBreakPairTable.txt
This file is special in the sense that it is
On Friday 22 December 2006 18:27, Luca Furini wrote:
Hi all
I have a patch fixing bugs 41019 and 41121, for both trunk and float
branch, and I'm wondering how it's best for me to proceed in order to
avoid merging problems: should I change both trunk and branch, or
just one of them?
The
I am wondering how/where I should put the UAX#14 code generation java
source and data files in our repository.
The obvious choice is the existing codegen directory. But it contains
all the font codegen stuff at the top level which I don't want to mix
with the Unicode stuff. So what I would
On Thursday 21 December 2006 18:44, Vincent Hennebert wrote:
Manuel Mall a écrit :
snip/
Also I didn't get any response to the question if we could/should
store the needed Unicode data files in the Apache repository.
Where do these files come from? Have they been modified? Do they have
On Thursday 21 December 2006 18:53, Manuel Mall wrote:
On Thursday 21 December 2006 18:44, Vincent Hennebert wrote:
Manuel Mall a écrit :
snip/
Also I didn't get any response to the question if we could/should
store the needed Unicode data files in the Apache repository.
Where do
On Thursday 21 December 2006 22:49, [EMAIL PROTECTED] wrote:
Manuel,
... I changed the code generation code to accept URLs and it
can read the Unicode data files directly from the Unicode site now.
Would that work if the machine that's running fop doesn't have access
to the internet?
Or
On Tuesday 19 December 2006 23:55, Manuel Mall wrote:
snip/
Its looking OK so far and most of the layout engine tests pass.
Just discovered the first instance of an existing testcase which gives a
different result. Under UAX#14 the following text (Note this is plain
text not FO markup
On Wednesday 20 December 2006 23:22, Chris Bowditch wrote:
Manuel Mall wrote:
On Tuesday 19 December 2006 23:55, Manuel Mall wrote:
snip/
Its looking OK so far and most of the layout engine tests pass.
Just discovered the first instance of an existing testcase which
gives a different
On Wednesday 20 December 2006 20:43, Manuel Mall wrote:
On Tuesday 19 December 2006 23:55, Manuel Mall wrote:
snip/
Its looking OK so far and most of the layout engine tests pass.
Just discovered the first instance of an existing testcase which
gives a different result.
Here is another
On Thursday 21 December 2006 06:08, J.Pietschmann wrote:
Luca Furini wrote:
snip/
Another doubt: why aren't the - signs in text-align and
linefeed-treatment possible breaks?
They should be, the dash in Unicode 5.0 has the property HY, which
allows for a break after. The tables I generated
Here is a sample from the test case I am developing attached.
The ..._old.pdf file shows the current fop-trunk behaviour while
the ..._new.pdf file shows what happens in the FOP UAX#14 version.
There are quite a few subtle differences (mostly for the better I hope).
I also attach the test case
Just a quick heads up that I finally took the plunge to add UAX#14 line
breaking to FOP. This is based on code donated by Joerg quite some time
ago on which I did some work in October 2005. This had been documented
on list at the time.
One of the major stumbling blocks in progressing this was
On Wednesday 20 December 2006 05:02, Simon Pepping wrote:
snip/
Manuel, can you hold your changes until the branch has been created?
No problems, will wait until the branch is there.
Regards, Simon
Manuel
On Thursday 02 November 2006 12:31, [EMAIL PROTECTED] wrote:
Dear Sir,
My name is Kalpesh A. Jain. Currently working as Software
Developer in Network Solution Pvt. Ltd., Bangalore, India.
In FOP latest version (i.e., 0.20.5),
Writing-mode-related
On Monday 09 October 2006 05:01, Kia Teymourian wrote:
Hi all,
Hi,
Jeremias already responded to you and my comments go in the same
direction. Firstly, its great that you want to look at this aspect. I
did investigate support for UAX#14 Unicode compliant line breaking over
a year ago. I
On Monday 02 October 2006 17:12, Andrejus Chaliapinas wrote:
Hello,
While some of you already told me that I should look through XSL-FO
for those calculations (Jeremias mentioned how I would get value of
14400) - I still would like to ask you if you could point me to any
document (probably
On Thursday 14 September 2006 07:34, J.Pietschmann wrote:
Jeremias Maerki wrote:
Ok, I consider myself defeated concerning the way we handle the
configuration file (See recent threads on fop-users). The Avalon
configuration approach is very nice for the developer but obviously
bullshit in
On Sunday 10 September 2006 20:52, Jeremias Maerki wrote:
Ok, I consider myself defeated concerning the way we handle the
configuration file (See recent threads on fop-users). The Avalon
configuration approach is very nice for the developer but obviously
bullshit in terms of
On Monday 28 August 2006 06:39, Jeremias Maerki wrote:
Gang,
I've finally finished (more or less anyway) the poster I plan to put
up at OpenExpo on 2006-09-20. I'd appreciate if someone could take a
quick peek and tell me if it's looking too ugly or if there are any
spelling mistakes. The
On Thursday 03 August 2006 16:47, Apache Wiki wrote:
Dear Wiki user,
...
Hi Jeremias,
just saw your improved keeps wiki and am wondering if an algorithm along
the following lines may do the trick to deal sensibly with different
keep strength values in the context of the Knuth breaking
On Thursday 03 August 2006 18:44, Jeremias Maerki wrote:
Hey Manuel,
that's a very interesting idea. I think that could work. To me it
looks like the biggest problems in the whole topic is determining the
right representation of keep values inside the LMs and implementing
.within-page for
On Thursday 03 August 2006 21:04, Simon Pepping wrote:
On Wed, Aug 02, 2006 at 06:44:28PM +0200, Vincent Hennebert wrote:
snip/
3b) Modify the chars-to-metrics mapping to handle things like
automatic ligatures, where several chars map to a single glyph
Here I think you can profit
On Thursday 13 July 2006 20:55, Jeremias Maerki wrote:
Subject says it all. I think it's time. They work pretty well and
have grown beyond sandbox state. I'm sure there maybe a few nits here
and there, but the same applies to the other renderers.
+1 from me.
Yes, I am biased on this matter
On Thursday 13 July 2006 22:09, Jeremias Maerki wrote:
What I tried to propose is mostly just that. Implementing some
shortcut that at least treats all integer values differently from
always with a constant penalty value. That gives FOP the
opportunity to relax while still allowing the rather
On Monday 19 June 2006 20:25, Jeremias Maerki wrote:
On 19.06.2006 13:38:56 Manuel Mall wrote:
On Monday 19 June 2006 16:45, Jeremias Maerki wrote:
On 18.06.2006 20:57:51 Simon Pepping wrote:
On Sun, Jun 18, 2006 at 07:36:45PM +0800, Manuel Mall wrote:
snip/
Or should we use
On Sunday 18 June 2006 18:53, Jeremias Maerki wrote:
I just realized we should think about the right moment to release
1.0. I guess the number of fixed bugs would suggest a new release
rather sooner than later. I originally thought about going for an
ApacheCon release but I didn't have enough
On Saturday 03 June 2006 17:35, Andreas L Delmelle wrote:
On Jun 3, 2006, at 05:14, Manuel Mall wrote:
snip /
I don't think anything is wrong here. The definition of
linefeed-treatment was changed in XSL 1.1 (its all part of
refinement now) and I believe we behave correctly with respect
On Saturday 03 June 2006 07:36, Andreas L Delmelle wrote:
On Apr 27, 2006, at 09:58, Jeremias Maerki wrote:
Sorry for the extra-late reply, still catching up...
However, I'm not sure it this is right, but
white-space-treatment is handled before any linefeed-treatment
handling
is
On Tuesday 16 May 2006 19:58, Jeremias Maerki wrote:
Some background on my latest change. I found out that certain
TrueType fonts were off vertically inside their line area. It turned
out it has to do with different interpretations of the ascender and
descender values which are part of font
On Sunday 07 May 2006 18:02, Jeremias Maerki wrote:
snip/
Note to FOP committers: Interestingly, the DejaVu font might actually
meet our needs license-wise if we want a set of fonts we can
redistribute. We'd only have to check with legal since the license is
not standard BSD. The drawback: The
On Friday 05 May 2006 00:46, KeithHarris wrote:
Oopse, sorry - Fop wasn't complaining about the shared id there - it
was b/c I'd got the same chunk in a different part of the fo file.
Following the old docs just brings up warnings (WARNING: Unknown
formatting object
On Saturday 06 May 2006 21:20, Manuel Mall wrote:
On Friday 05 May 2006 00:46, KeithHarris wrote:
Oopse, sorry - Fop wasn't complaining about the shared id there -
it was b/c I'd got the same chunk in a different part of the fo
file. Following the old docs just brings up warnings (WARNING
I wonder if we should agree on some guidelines for the use of namespaces
(namespace prefixes) for extensions. I am thinking along the following
lines:
The namespace http://xmlgraphics.apache.org/fop/extensions; (common
prefix fox) is reserved for generic extensions to FOP supported
across all
On Friday 28 April 2006 17:18, Jeremias Maerki wrote:
Good stuff! Big thanks to Pete, Joe and Manuel for your work on the
AFP Renderer and for enduring the ASF bureaucracy.
Some initial comments on the code:
- I've already mentioned the tab characters to Manuel. He's looking
into them
On Friday 28 April 2006 19:25, KeithHarris wrote:
Great stuff Manuel - this has gone straight into my project and is
producing perfect afps. All I had to do was add a version of the
configuration file you circulated on the old afp list
On Thursday 27 April 2006 15:58, Jeremias Maerki wrote:
snip/
Any insight, whitespace specialists?
Not sure I fit into the category mentioned above but I'll look into it
later today.
snip/
Jeremias Maerki
Manuel
I just committed the first version of the AFP Renderer to the Sandbox.
This was pending for some time and after the IP clearance process has
now been completed the renderer can finally be put into the Apache
repository.
I hope it all compiles / builds correctly and no files have been missed.
On Friday 07 April 2006 23:13, Manuel Mall wrote:
On Friday 07 April 2006 19:14, Manuel Mall wrote:
On Friday 07 April 2006 16:06, Jeremias Maerki wrote:
On 06.04.2006 20:50:18 Peter S. Housel wrote:
snip/
Committed my changes.
As far as I can tell the various text-align property values
On Thursday 06 April 2006 23:09, Jeremias Maerki wrote:
We originally wanted to do a release much earlier but I was always in
the middle of something and I think I'm simply the only one who can
allocate enough time to do an actual release (prove me wrong,
please). I think I can make time next
On Friday 07 April 2006 16:06, Jeremias Maerki wrote:
On 06.04.2006 20:50:18 Peter S. Housel wrote:
WDYT?
From my perspective as a user, I think it's essential to fix the
problem
with preserving whitespace after a newline (for pre-style output)
before doing another release.
We currently allow the property value no-wrap for the white-space
shorthand property which matches the property value no-wrap for the
wrap-option property.
However, the spec seems to say that for white-space the property value
is nowrap (no hyphen) while for wrap-option it is no-wrap.
I
I am getting the warning below when compiling the latest trunk
Manuel
[javac]
/home/mm/fop-trunk/src/java/org/apache/fop/pdf/PDFOutputIntent.java:121:
warning: unmappable character for encoding UTF8
[javac] * document�s source colors to
output device
On Tuesday 04 April 2006 03:38, Simon Pepping wrote:
Hello,
snip/
Simon,
very interesting approach to the problem. You obviously gave this quite
a significant amount of thought.
While your approach may simplify many Knuth sequences for the less
common (or more convoluted) cases you clearly
I spent a little time on the Apache Licensing page, and didn't find
anywhere that said it was compatible (I'm not saying it isn't
compatible, just that I didn't see anything that said it was... in
the 5 minutes I looked). As for the rest of the licensing stuff, I
don't know. But the answer
On Wednesday 08 March 2006 00:00, [EMAIL PROTECTED] wrote:
Hi there,
while working through my notes I found a point strange things. I
think I mentioned this before as some kind of footnote or BTW. I'm
getting used to the rule to write variable definitions (even if
private) at the class' top.
On Wednesday 01 March 2006 06:37, Jeremias Maerki wrote:
snip/
Does anyone of you plan to work on the UAX#14 stuff?
I would love to. See
http://marc.theaimsgroup.com/?l=fop-devm=113074361626846w=2 where I
documented the work I did with Joerg's code. Same as Joerg I would
prefer a poll
On Monday 27 February 2006 18:55, Jeremias Maerki wrote:
What's the status of UAX#14? Does anybody have had time to work on
that, yet? I'm asking because I'm considering hacking in support for
the fixed width spaces (U+2000..U+200A). One of my clients asks for
that but I can't allocate enough
On Monday 27 February 2006 21:33, Jeremias Maerki wrote:
On 27.02.2006 12:36:58 Manuel Mall wrote:
On Monday 27 February 2006 18:55, Jeremias Maerki wrote:
What's the status of UAX#14? Does anybody have had time to work
on that, yet? I'm asking because I'm considering hacking
On Monday 27 February 2006 22:12, Jeremias Maerki wrote:
On 27.02.2006 14:59:31 Manuel Mall wrote:
On Monday 27 February 2006 21:33, Jeremias Maerki wrote:
On 27.02.2006 12:36:58 Manuel Mall wrote:
On Monday 27 February 2006 18:55, Jeremias Maerki wrote:
snip/
Wait a sec! suppress
On Monday 27 February 2006 22:53, Jeremias Maerki wrote:
On 27.02.2006 15:22:14 Manuel Mall wrote:
On Monday 27 February 2006 22:12, Jeremias Maerki wrote:
On 27.02.2006 14:59:31 Manuel Mall wrote:
On Monday 27 February 2006 21:33, Jeremias Maerki wrote:
On 27.02.2006 12:36:58
On Monday 27 February 2006 23:16, Jeremias Maerki wrote:
On 27.02.2006 16:02:32 Manuel Mall wrote:
On Monday 27 February 2006 22:53, Jeremias Maerki wrote:
On 27.02.2006 15:22:14 Manuel Mall wrote:
On Monday 27 February 2006 22:12, Jeremias Maerki wrote:
On 27.02.2006 14:59:31
On Monday 27 February 2006 23:37, Jeremias Maerki wrote:
I'm considering removing the character area tree object and instead
map an fo:character to a normal text area with one word child.
fo:characters are rarely used so this doesn't add much to the memory
consumption of the area tree but
On Tue, Feb 14, 2006 at 10:26:52AM +0100, Luca Furini wrote:
In order to preserve all spaces, we could use the elements that are now
generated for a nbsp:
box w=0
penalty inf
glue (elastic or not, according to the alignment)
They are not suppressed and they do not allow a break,
.
Manuel,
see 7.28.4. provisional-distance-between-starts and 5.10.4. Property
Value
Functions
In the source code: org.apache.fop.fo.expr.BodyStartFunction
On 13.02.2006 09:31:47 Manuel Mall wrote:
Jeremias,
just out of curiosity and not directly related to the posters question
On Monday 06 February 2006 18:44, Luca Furini wrote:
Manuel Mall wrote:
snip/
1. Justified text: pen INF + elastic glue
2. All other justification modes: either just a box of the width of
the space or pen INF + fixed width glue.
I think in both cases (justified / unjustified text) we
On Monday 06 February 2006 22:35, Luca Furini wrote:
Manuel Mall wrote:
IMO nbsp (and any other Unicode special spaces) are outside the
scope of XSL-FO whitespace handling. XSL-FO refers to whitespace as
defined in XML. In XML only x#20, x#9, x#a, and x#d are considered
whitespace
On Feb 5, 2006, at 14:13, [EMAIL PROTECTED] wrote:
Hi Manuel,
--- Additional Comments From [EMAIL PROTECTED] 2006-02-05
14:13 ---
snip/
A preserved carriage return can be treated the same way as a
linefeed, under the very exceptional condition that it survives white-
space
1 - 100 of 341 matches
Mail list logo
