Hi all,
There’s something quite strange in the layout code that I suspect comes
from the pre-Knuth era.
AbstractLM defines a reset method that among other things calls
resetPosition on children LMs. If you search for references to this
reset method, you find out that it is only called within
Hi all,
This one is for FO tree and Layout Managers specialists.
It seems to me that TableRowIterator should act during the FO-tree
building rather than layout, as is currently the case. The main reason
is that some validation like spanning cells that overlap can only be
done once we start
Hi,
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 wondering why we don't apply the KISS principle here?
IIRC the original problem was that the FOP memory footprint for
Hi Clay,
The Web Maestro a écrit :
On 7/31/07, Vincent Hennebert wrote:
I've committed my changes, so the site should be re-factored. There is
likely a bunch of content in the '0.94' realm that needs updating so
it's more relevant to the current release. In addition, there may be
some pages
Hi Adrian,
Adrian Cumiskey a écrit :
Hi,
Currently the AFPRenderer is fixed to use a calculation against a static
final DPI_CONVERSION_FACTOR_240 to produce 240 dpi output. I've looked
at the code, and it looks fairly straight forward to introduce an extra
configuration setting which would
Hi all,
Caution, long post ;-)
I’ve been thinking about the handling of keeps and breaks in tables for
a while, and it seems to me that improvements could be done in that
whole area. I’ll use break-before as an example but what I’ll be saying
applies to break-after and keeps as well.
Sorry, attached the wrong FO file. Here it is.
Vincent
?xml version=1.0 standalone=no?
fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format;
fo:layout-master-set
fo:simple-page-master master-name=page
page-height=10cm page-width=15cm margin=1cm
fo:region-body/
Hi,
I’m suddenly all confused about the supposedly expected behaviour of
breaks. Please have a look at the attached FO file and its PDF result.
We get 2 pages. The break-before on the outer block and the inner block
are “merged” into just one... Why?
Section 4.8, “Keeps and Breaks” of XSL-FO
Hi Clay,
The Web Maestro a écrit :
Hi Vincent,
On 8/2/07, Vincent Hennebert wrote:
snip/
Thanks for the pointers. By adding the following in skinconf.xml:
#content { font-size: 100% }
I managed to get normal size for the main text. I didn't commit the
change because I wasn't sure
Hi Mark,
Mark C. Allman a écrit :
Drop RTF with nothing to replace it, e.g., ODF? I'd rather not.
Swap out RTF with, say, ODF? Sounds great to me.
I'd even volunteer some time to help with development. I seem to
remember something about Java ;-]
Thanks for your offer to help!
Hi Clay,
Thanks for chiming in!
It seems we are somewhat duplicating our efforts here. I already removed
the 0.20.5 tab and added a new one for 0.94. Look at the 0.94 branch of
the svn repository. I prefer to work in the branch so that the trunk
stil reflects the current site, and we can
Taking advantage of this to drop a note to developers (including
myself...).
Author: jeremias
Modified:
xmlgraphics/fop/trunk/status.xml
Please try and think of updating this file whenever you commit a notable
modification, that’s very important for tracking changes and seeing
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 there is
about one person who could help / modify the code, and
Hi all,
The 0.94 version of FOP is basically ready to be released. The poll on
fop-user gave interesting results, although not applicable to the next
release. What about creating a wiki page summarizing those user wishes?
Users could then maintain it by themselves. Andreas, would you be
willing
Hi Max,
Max Berger a écrit :
Vincent,
Vincent Hennebert schrieb:
snip/
Your idea of using manifest.xml looks fine. A quick Google search didn't
give me any result regarding a standard way of bundling fonts with Java
apps. It looks like you did also search for that before going
Hi Adrian,
Adrian Cumiskey a écrit :
Hi all,
I realise this isn't a FOP question but when I try to update my trunk
sandbox with subversion I get svn: Delta source ended unexpectedly.
Does anyone else experiencing this problem?
svn up -N (non-recursive update works fine)
and so does a
Hi Jens,
Jens Bannmann a écrit :
Vincent Hennebert wrote:
Question is, also, how to advertise the thing. Would the fop-user
mailing list be enough to attract donators?
From a quick search, it doesn't seem that the topic was brought up
previously on that list. Can anyone think of another
Hi all,
Author: vhennebert
Date: Sat Jul 21 02:50:32 2007
New Revision: 558281
URL: http://svn.apache.org/viewvc?view=revrev=558281
Log:
Initialize merge tracking via svnmerge from the Trunk
(for applying to the 0.94 branch the applicable changes in the Trunk)
Modified:
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 attached FO file and the resulting PDF
I get? There's a word joiner
Hi Andreas,
My 2 cents on this, as I have a rather limited understanding of this area.
Andreas L Delmelle a écrit :
snip/
org.apache.fop.fonts.Font contains a fontSize member. I would like to
see this separated from the Font instance somehow. Instead of fetching a
Font corresponding to given
Hi,
I second that, a good idea for sure!
Regarding how this may be done within the ASF, that's probably a
question we can ask on [EMAIL PROTECTED] Maybe the ASF itself can serve as
the SPP platform?
I think it's worth making a poll on fop-user to see how many users would
be ready to participate
Well done, Andreas!
snip/
In the process, some oddities that caught my eye in the javadocs were
corrected as well. On the other hand, I do not completely rule out that
new oddities have been introduced (the diff being +16000 lines), so keep
your eyes open for those...
IMO it's perfectly fine
Hi,
Manuel Mall a écrit :
On Wednesday 18 July 2007 02:58, Andreas L Delmelle wrote:
snip/
Interestingly Java 1.5 has added the Integer.valueOf(int) method with
the following comment:
Flyweight pattern. That's what I was looking for before replying to
Andreas' commit, and I was surprised to
Hi Andreas,
Andreas L Delmelle a écrit :
On Jul 14, 2007, at 15:59, Vincent Hennebert wrote:
Vincent
Andreas L Delmelle a écrit :
Tested locally, and is OK here. If you'd like, I can run a sanity diff
later tonight, and commit the changes sometime tomorrow.
Thanks, Andreas. We should
Hi Adrian,
I'm not really a specialist of the font handling stuff in FOP, but
having worked a bit in this area I can drop a few ideas (and ask a few
naive questions), in the hope they will be useful.
In the process of looking at this bug
Hi Andreas,
Author: adelmelle
Date: Fri Jul 13 12:21:03 2007
New Revision: 556112
URL: http://svn.apache.org/viewvc?view=revrev=556112
Log:
Addition of a general-purpose int-to-int map to replace Integer-to-Integer
HashMaps + first usage in TTFFile
Added:
J.Pietschmann a écrit :
Jeremias Maerki wrote:
Yes, inheritDoc would be the right way, as long as we're on Java 1.4.2
and later (feature not available in 1.3, severly buggy in 1.4.0/1.4.1. I
would have switched a long time ago if we weren't still on 1.3.
I think of JavaDoc as a sort of
Hi Andreas,
Andreas L Delmelle a écrit :
snip/
I propose the following plan:
- make a list of patches/bugs that we would like to apply/fix before
releasing. Here everyone can help, even non-committers ;-) Once the
list is done we will see how many of them we can handle.
Shall I post a
Andreas L Delmelle a écrit :
On Jul 14, 2007, at 13:27, Vincent Hennebert wrote:
J.Pietschmann a écrit :
snip/
I think of JavaDoc as a sort of compile time feature. I don't think
there's still a reason to generate the JavaDocs with a JDK version
older than 1.5. It's the byte code which should
Hi all,
I'll soon start the release process for XML Graphics Commons. There's
not much to do there, apart from updating the website content. Meanwhile
I'd like to enter some kind of freezing phase in the FOP area. That is,
mainly, avoid to perform too big changes which might introduce
Hi,
Nothing related with (and against) the original change, but I take this
one as an opportunity to launch the discussion. I've been having this in
my head for a while.
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java
Modified:
Jeremias Maerki a écrit :
On 13.07.2007 15:45:01 Vincent Hennebert wrote:
snip/
Speaking of branches, I noticed that there are many (very) old branches
on Subversion. What about removing them?
-1. If you want to clean up, please create a subdirectory old-tags (or
similar) and move the old
Adrian Cumiskey a écrit :
The junit-layout-standard target seems to broken on trunk...
My bad, sorry. I didn't think of table cells with content of zero
length, which was the root of the problem... I've committed a temporary
hack as I'm in the process of heavily changing this part of the code.
Hi guys,
Title says it all. FOP 0.93 was released the 9th of January. I think
it's time to release the next version, as many bugs have been corrected
and many exciting new features added.
Anyone against a new release?
I'd volunteer to deal with all the release process... unless someone
Hi Max,
Max Berger a écrit :
Vincent,
I would love to have Bug 42785 ( patch to support baseline-shift )
applied before the release, because then I could release a new plugin
for the new version. I've read your comment, and I will check with the
spec which options I have to improve the
Hi all,
Another question regarding backgrounds. See the attached FO file and the
resulting PDF. Cell 1.1 is spanning over 2 rows. Its border-right is
composed of 2 segments, one thicker and one thinner. For the latter, the
gap is currently filled with the table's background.
Question is:
Hi,
On behalf of the XML Graphics PMC I am pleased to announce that we have
two new active contributors to FOP:
- Max Berger
- Adrian Cumiskey
Many thanks for your contributions, and we hope that you will continue!
Vincent
Hi Max,
--- Additional Comments From [EMAIL PROTECTED] 2007-05-23 02:07 ---
Created an attachment (id=20244)
-- (http://issues.apache.org/bugzilla/attachment.cgi?id=20244action=view)
Yet another try
I was about to hit return after having entered the svn commit command...
when I
Hi Richard,
Thanks for your contribution. I'll try to have a look ASAP but I'm a bit
in a hurry currently. Stay tuned.
Vincent
richardw geoquip-rnd demon co uk a écrit :
Vincent Hennebert writes:
I fully agree. Good design should not be sacrificed for efficiency.
Anyway only
Hi,
This is probably for Jeremias... See the border between cell 2.1 and
cell 3.1 in the second table of this testcase. The area tree is correct,
but the painting is weird, there is some blank area between the two
border-halves. This occurs in PDF, PS and AWT outputs.
This is more for the
Hi Jeremias,
Jeremias Maerki a écrit :
Great news, Vincent! Good stuff!
Thanks! Although there is still some work to do.
Of course, I had to try it out immediately and it looks promising. Still,
I've got a few points for you to look into:
- Please reenable the two test cases for border
Hi,
Is there any reason why SpaceHandling[Break]Position elements created by
SpaceResolver don't have any LayoutManager associated to them?
As a result, in AreaAdditionUtil.addAreas, if the first Position element
is a SpaceHandling[Break]Position, then the position list is not
iterated over to
Hi Jay,
Jay Bryant a écrit :
snip/
- if your modifications are non-trivial (as is the case here), it's very
important to add a note about them in the status.xml file. The content
of this file appears on the following web page:
http://xmlgraphics.apache.org/fop/changes.html
Where? In the
Hi Paul,
Paul Vinkenoog a écrit :
Hello Vincent,
+public int compare (Object obj1, Object obj2) {
+if (obj1 instanceof PDFDestination obj2 instanceof
PDFDestination) {
+PDFDestination dest1 = (PDFDestination)obj1;
+PDFDestination dest2 = (PDFDestination)obj2;
and
break-after properties on fo:table-row and children of fo:table-cell
which are themselves children of fo:table-header and fo:table-footer
elements. It might be helpful to explicitely state that in the
descriptions of break-before and break-after.
I hope I was myself clear!
Thanks,
Vincent Hennebert
actually be discarded or not.
While this interpretation makes sense and would match users'
expectations, I'm not sure if it is really intended by the
Recommendation. So could you please provide a clarification on this
subject?
Thanks,
Vincent Hennebert
?xml version=1.0 standalone=no?
fo:root xmlns:fo
Hi Jay,
First, congratulations for this new feature! This is a great addition to
FOP.
A few remarks about your commit:
- I suggest you to install and setup checkstyle if you haven't done yet;
- don't forget to add the ASF headers (checkstyle will notify you about
that, BTW) and set the
Hi Andreas,
Andreas L Delmelle a écrit :
On Mar 30, 2007, at 11:21, Vincent Hennebert wrote:
snip/
In ancient times, each FO had a full PropertyList, so the properties
could be queried via a generic get(PROPERTY_ID) accessor that was simply
a proxy to the PropertyList's corresponding get
Hi Andreas,
I have little knowledge of the FO tree construction, so I'll perhaps
make naive questions and remarks. I write them in the hope they will
trigger further thoughts.
Andreas L Delmelle a écrit :
Hi,
Just an idea that popped in my head. I was thinking of the access to a
FONode's
Guys,
When running the layoutengine testsuite, it is possible to use several
properties to select the testcases you want to run. As a reminder
everything is explained here:
http://wiki.apache.org/xmlgraphics-fop/HowToCreateLayoutEngineTests
You can exclude the disabled testcases to be run by
Hi Andreas,
Andreas L Delmelle a écrit :
On Mar 27, 2007, at 10:47, Vincent Hennebert wrote:
Andreas L Delmelle a écrit :
On Mar 26, 2007, at 16:48, Vincent Hennebert wrote:
I'm having a lot of fun playing with border and padding
conditionalities...
snip /
Just a sanity check: aren't
Hi Paul,
So you wanna join the game? ;-)
Paul Vinkenoog a écrit :
snip/
The (1.1) spec says that if the positioning is...
- absolute:
the positions are taken with respect to the nearest ancestor
reference area;
- fixed:
the positions are taken with respect to the page viewport
Hi Andreas,
Andreas L Delmelle a écrit :
On Mar 26, 2007, at 11:47, [EMAIL PROTECTED] wrote:
If I understand you correctly, what you're saying is that if the fixed
positioned block's nearest ref-area is not initially visible, then the
top/left/etc. properties should be taken WRT the
Hi Andreas,
Andreas L Delmelle a écrit :
On Mar 26, 2007, at 16:48, Vincent Hennebert wrote:
Hi Vincent,
I'm having a lot of fun playing with border and padding
conditionalities...
snip /
I think the padding should actually not be discarded on the second page.
It would
Hi Luca,
Luca Furini a écrit :
Hi all
I recently had the time (and the pleasure) to look at before-float
implementation branch, and I played a bit with it.
I focused on the handling of footnotes, as I noticed that sometimes they
were placed on a page following their citations without a
Grmblmblm... and the attached fo file, of course...
Vincent
Vincent Hennebert a écrit :
Hi Luca,
Luca Furini a écrit :
Hi all
I recently had the time (and the pleasure) to look at before-float
implementation branch, and I played a bit with it.
I focused on the handling of footnotes
Hi Andreas,
Andreas L Delmelle a écrit :
On Mar 23, 2007, at 11:22, Vincent Hennebert wrote:
Thanks for your perseverance ;-)
You're welcome. :o)
I'm sure we will manage!
snip /
If the nearest ancestor ref-area is not immediately visible, then I
think this implies that the fixed
Hi,
Thanks for your inputs, Andreas and Jeremias.
The whole thing suddenly makes sense when you think in terms of area
tree instead of fo tree...
Still, I think it's not obvious by reading the spec and I'll probably
ask for clarification on [EMAIL PROTECTED]
And there is a remaining question
Hi all,
I'm having a lot of fun playing with border and padding
conditionalities... What do you think of the attached fo file (resulting
pdf also attached)?
I think the padding should actually not be discarded on the second page.
It would if the corresponding edge were a leading edge in the
Hi,
Jeremias Maerki a écrit :
On 22.03.2007 11:41:28 Vincent Hennebert wrote:
Hi,
snip/
This raises the question as to how retained borders and paddings are
handled: their widths will count in the penalty width of resolved break
elements. How are borders from elements surrounding the list
Jeremias,
Author: jeremias
Date: Fri Mar 23 02:19:04 2007
New Revision: 521640
URL: http://svn.apache.org/viewvc?view=revrev=521640
Log:
Avoid an IndexOutOfBoundsException when more columns are used than are
specified even though this is illegal with fixed table layout.
What about our
that, yes. We would then have two methods of iterating
over tables: one fast, memory-efficient relying on columns
specifications, and one slow, memory-consuming parsing the entire table
before doing anything else.
Vincent
On 23.03.2007 12:30:02 Vincent Hennebert wrote:
Jeremias,
Author: jeremias
Guys,
I've again stumbled upon uncertainties regarding the handling of
conditional borders in the collapsing-border model, and breaks inside
headers/footers. I'd like to have your opinions on these:
Table headers and footers:
Headers and footers are generated only once, and replicated on each
Jeremias Maerki a écrit :
On 23.03.2007 15:44:57 Vincent Hennebert wrote:
Guys,
I've again stumbled upon uncertainties regarding the handling of
conditional borders in the collapsing-border model, and breaks inside
headers/footers. I'd like to have your opinions on these:
Table headers
Jeremias Maerki a écrit :
On 21.03.2007 21:22:04 Andreas L Delmelle wrote:
On Mar 21, 2007, at 10:42, Vincent Hennebert wrote:
snip /
Whatever follows in that second definition is irrelevant wrt
determining the base for percentage values to compute the initial
offset (or IOW
Hi,
A small question: am I true that the element list passed as parameter of
the SpaceResolver.resolveElementList method should be delimited by
reference areas?
That is: as there is a fence before (and after) a reference area, there
will never be stacking constraints crossing ref-areas's
Hi Andreas,
[EMAIL PROTECTED] a écrit :
- Oorspronkelijk bericht -
Van: Chris Bowditch [mailto:[EMAIL PROTECTED]
snip /
AFAICT, I don't think you've got everything nailed down here. As Vincent
already mentioned the ancestor reference area could change depending on
the value of
Hi Jeremias,
Thanks for your answers.
Jeremias Maerki a écrit :
On 17.03.2007 01:37:16 Vincent Hennebert wrote:
Hi,
There are things unclear to me in the addAreasAndFlushRow method of the
RowPainter class. I hope someone can shed some light:
I wrote this a long time ago. Let's hope I can
Hi,
[Andreas]
This should indeed be handled better, but your FO is actually very dubious...
In fixed-layout, the number of columns and their respective widths are
ultimately determined based on
the cells in the first row. There is no obligation for an implementation of
XSL-FO to even
Hi,
Again I'd like to share my thoughts. I've been looking for a while for
a means to unit-test the layout code. There are two difficulties
I think:
- re-creating the necessary LayoutManager structure. While it would be
great to be able to create only the necessary LMs (e.g., TableLM and
its
Hi,
There are things unclear to me in the addAreasAndFlushRow method of the
RowPainter class. I hope someone can shed some light:
- why is a Map used to store y-offsets of rows? That seems to indicate
that rows are not added in a sequential order, or that there could be
hole between them,
[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 at the Area Tree XML. The
label has a BPD of 18936 while the
Andreas,
First, many thanks for your explanations!
Some comments below.
Andreas L Delmelle a écrit :
On Mar 8, 2007, at 20:15, Andreas L Delmelle wrote:
Hi Vincent,
On Mar 8, 2007, at 18:29, Vincent Hennebert wrote:
snip /
Now, does that picture represent the current code
that picture represent the current code? If not, what is
missing/wrong, apart from the many details relevant to each particular
LM? Does that make sense?
Thanks,
Vincent
Jeremias Maerki a écrit :
On 07.03.2007 15:28:37 Andreas L Delmelle wrote:
On Mar 7, 2007, at 09:07, Vincent Hennebert wrote:
Hi
Hi,
I have some questions regarding the handling of Position elements. I'm
not familiar with that part of the code yet, and as there is little or
no javadoc for those it's a bit difficult to guess their purposes just
by looking at the code.
What's the purpose of a LeafPosition? Of a
Jeremias Maerki a écrit :
Vincent,
can I please ask you to put code guards (if (log.isDebugEnabled())...)
around debug and trace log statements? This avoids unnecessary string
concatenation if the respective log level is diabled.
See also:
Hi Andreas,
Andreas L Delmelle a écrit :
Anyone here going to Amsterdam (or: 'staying there' would be more
fitting for Simon) in May?
Yes I should be going there, just waiting for the special registration
code providing a discount for Apache committers.
I can make it only on the opening
Christian Geisert a écrit :
[EMAIL PROTECTED] schrieb:
Author: vhennebert
Date: Wed Feb 14 01:32:03 2007
New Revision: 507449
URL: http://svn.apache.org/viewvc?view=revrev=507449
Log:
I thought the svn:eol-style and svn:keywords properties were automatically
set on java and fo files.
Guys,
It may be worth clarifying which version of XSL-FO we officially
support, now that 1.1 has reached the status of a recommendation. I
guess we can now take it as a reference, since it clears some
uncertainties of the 1.0 version. I've just noticed that I'm myself
still looking at the 1.0
Hi All,
I think the codebase is seriously lacking of unit tests, which makes
refactoring a bit hazardous. Of course there is the wonderful
layoutengine testsuite that allows to check if a XSL-FO file is rendered
as expected (BTW, I don't remember who introduced this feature, but a
huge thanks to
Hi Adrian,
Adrian Cumiskey a écrit :
Vincent Hennebert wrote:
Yes, the patch doesn't seem to break anything. We could even go a bit
further: the cfg parameter is no longer used in the
FOUserAgent.configure() method, it might be removed. Also, would the
FopFactory.getUserConfig() method
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=41514.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Hi Adrian,
Sorry for the delay. I've had a look at your patch. First of all, thanks
for taking care of this. Strong validation of user config files is
a great step towards user-friendliness. Thanks also for thinking of
documentation and testcases!
I have a few comments, some of which are open
Hi Adrian,
Adrian Cumiskey a écrit :
snip/
- we may discuss about the interest of a separate/yet another parameter
for validating the config file. I can understand both points of vue
and, actually, I don't really care of which is chosen. That said,
I think validation of the config file
Chris Bowditch a écrit :
Jeremias Maerki wrote:
Do I have a slightly distorted perception or do we currently see an
increase in activity, even patches, following the 0.93 release?
Hi Jeremias,
yes I think there has been a increase in both user and development
activity in the few weeks
Luca Furini a écrit :
I agree that, in a sense, the error is in the fo file, defining a
fixed-height footnote separator that does not fit well the page; with an
heigth of 12 pt, all would be ok. In alternative, it could be defined
using a min-opt-max line height or space-*, allowing for some
Hi Luca,
Luca Furini a écrit :
Hi all!
At long last, I'm finally allowed some time to look at the float branch
and ... wow! Really impressive, a great lot of good work!
Well, thanks!
In order to apologize for my long absence :-) , I'm trying to see what's
wrong with the failing
Andreas L Delmelle a écrit :
On Jan 15, 2007, at 22:20, Andreas L Delmelle wrote:
snip /
Not really sure what would be most efficient:
- a void method appending to a parameter StringBuffer
- a method returning a copy of the char[] from index to index...
Seen that every String ultimately
Hi Andreas,
Andreas L Delmelle a écrit :
On Jan 9, 2007, at 15:22, [EMAIL PROTECTED] wrote:
Author: vhennebert
Date: Tue Jan 9 06:21:59 2007
New Revision: 494416
URL: http://svn.apache.org/viewvc?view=revrev=494416
Log:
In relaxed validation mode, it should be acceptable to have
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,
when I implemented the UAX#14 line breaking I noticed that fop doesn't
currently support the Unicode
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 (SHY).
I am thinking of adding support for this character to
Jeremias Maerki a écrit :
Website redeployed. I guess I need to switch back to SVN deployment so
everyone can do it. Will do ASAP.
But how is it done currently? When I change a file in the xdocs
directory of the trunk, it eventually appears on the website. So I
thought there were some automatic
The Web Maestro a écrit :
On 1/10/07, Yannick Valot wrote:
Trouble is, http://www.apache.org/dyn/closer.cgi/xml/fop
eventually leads you to the old xml/fop directories, which are still
available (maybe to keep old links working), contain lots of old data,
fop-current files which certainly
Richard a écrit :
snip/
I'm also currently reading through Knuth's Digital Typography. Can anyone
point out any sections I should pay particular attention to w.r.t. FOP's
usage,
(Digital Typography caught my eyes. I'll try to respond to the rest
later.)
Chapter 3, Breaking Paragraphs Into
I can handle the docbook-apps list.
BTW, my annoucement for XMLGraphics Commons 1.1 never appeared on the
Batik-users list. It did on Fop-users, although my Apache address isn't
subscribed to this list. Any idea of what's wrong?
Vincent
Simon Pepping a écrit :
The announcement email for FOP
Simon Pepping a écrit :
On Tue, Dec 19, 2006 at 09:02:06PM +0100, Simon Pepping wrote:
As discussed recently, I will prepare a release of FOP, to be named
0.93.
I have committed fixes for the reported issues with the dist files. I
have also fixed a few other issues I discovered. I have
Nice work, Manuel! That will be a great addition to Fop.
I have never studied the problem in detail, so I can only give a general
opinion. But I think we should follow as closely as possible the Unicode
standard, even if that leads to behaviors incompatible with the current
one. It seems the
Manuel Mall a écrit :
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
Guys,
If I'm correct the StrokeSVGText is no longer available in the new
codebase? Can I remove the paragraph [1] about it in the doc?
[1] http://xmlgraphics.apache.org/fop/0.92/graphics.html#svg-pdf-text
(As you can see I'm currently checking the consistency of the
documentation before releasing)
On the Upgrading page [1] it is stated that The new FOP extension for
Barcode4J will be available in January 2006. By quickly looking at the
Barcode4J I haven't found any relevant information about that
601 - 700 of 801 matches
Mail list logo
