Christian,
would you please add the "0.92" version to Buzilla? Thanks.
Jeremias Maerki
Apache Wiki ?
>
> http://wiki.apache.org/general/SummerOfCode2006
>
> Is it better to go through that page, or will our proposals be forwarded
> directly to you anyway ?
>
> Thanks,
>
> Patrick
>
> Jeremias Maerki wrote:
>
> >I don't see why
ems on this list.
>
> To be able for users to use the renderer properly some documentation has
> to be added to our web site as especially the font configuration is
> fairly special. I'll hopefully get around to do that in the next few
> days.
>
> Manuel
Jeremias Maerki
that be mostly because I had more
important things on my list. I don't need MathML myself. I'm only
available to faciliate the integration if there are people actively
pushing it.
Jeremias Maerki
've added an entry for floats implementation.
> >
> > I'll be off-line from tomorrow until the 6th of may. Just hoping no
> > particular problem will occur during my absence. Anyway, if I don't
> > answer mails that's just normal.
> >
> >
>
current status of this? What are the
> MB> license / technical issues? Is this desired at all?
>
> MB> Here is what I would like to see:
> MB> - include jeuclid in xmlgraphics
> MB> - add code to fop to support the inclusion of "mml" documents as
> MB> external images.
> MB> - add code to fop to support mml embedded within fo documents
>
> MB> i would be willing to provide the first two items, if it is legal to
> MB> do so...
>
> MB> Max
>
>
>
>
> --
> Best regards,
> Gennadiymailto:[EMAIL PROTECTED]
Jeremias Maerki
hat we will continue making half-year commits to the
> sf.net repository with patched FOP and JEuclid which fully covers our
> needs.
Not a very promising prospect. That's certainly not how you can attract
possible users.
> If somebody would be interested for somebody to integrate into
> FOP thunk, s/he is welcome.
I'll handle that.
Jeremias Maerki
verride.java
> org.apache.fop.layoutmgr.inline.BidiLayoutManager.java
>
> And then add some classes for the Arabic character shaping like
> ArabicLigaturizer.
> The bidi-Override implementation is very useful for some other projects
> to be able to
> create Persian/Arabic Documentation with PDF output from DocBook files.
>
> Regards,
> Kia Teymourian
>
>
>
Jeremias Maerki
On 05.05.2006 10:51:35 Peter B. West wrote:
> On Fri, 2006-05-05 at 08:43 +0200, Jeremias Maerki wrote:
> > This is good news. I did not study the problems around non-LTR texts so
> > I can't say anything useful about this.
> >
> > I think it is preferrable t
r drivers and simply render the text as
raster graphics. The file size remains surprisingly small. I just don't
know if it has any negative impact on performance. And I wonder if
there's a reason why the TrueType fonts are not embedded. Hmmm.
Jeremias Maerki
.2006 18:27:50 Patrick Paul wrote:
> Hi Jeremias,
>
> Any news from GSoC ? Were you able to see my application and rank it ?
> How are things going within the ASF ?
>
> Patrick
>
> Jeremias Maerki wrote:
>
> >It looks like you two need to sign up for the GSoC
-end,
You, too.
> Patrick
>
> Jeremias Maerki wrote:
>
> >Hi Patrick,
> >
> >green lights everywhere. I've already ranked it and applied for the
> >mentor position. It turns out that the Wiki in the ASF this time only
> >was about collecting ideas for projec
e kind of conversion methods
and the same quality for each kind. For normal users, it may be overkill
and may only produce confusion, but on the other side, they may never
need that. Maybe we need both: fox and output-format-specific. The
renderers first inspect the fox hint and then look for a
renderer-specific hint.
Jeremias Maerki
Will do.
On 07.05.2006 12:20:57 Manuel Mall wrote:
> On Sunday 07 May 2006 18:02, Jeremias Maerki wrote:
>
> > 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&#
hat we can use these fonts (in binary)
within Apache FOP (in SVN and maybe to be bundled in our distributions).
Thanks a lot!
Jeremias Maerki
same block. It still had issues
> like above. I then put each table in to its own span all block
> interleaved with a , a zero width space.
> This produced the results I needed. Haven't tested what would happen if
> a single row spanned 2 or more pages.
>
> Does this make sense? Is this a bug like I thought?
>
> Regards
> Adam
>
>
Jeremias Maerki
so I wonder if it has to be reviewed first or if the submit
> has failed. The way the webapp works isn't clear to me yet. Do you see
> my application?
Jeremias Maerki
Got it and rated it. All green! :-)
On 07.05.2006 22:24:26 Vincent Hennebert wrote:
> Ok, this should have worked this time. Don't know what happened.
>
> Vincent
>
>
> Jeremias Maerki a écrit :
> > Vincent, I'm afraid I don't see your application, ei
ote on batik-dev I failed to guide Thomas
into the right direction by not being strict about handling the vote as
an explicit PMC vote. He was right to CC general@ but I didn't make it
clear with my vote, for example, that it is actually a PMC thing. My
apologies, Thomas.
Jeremias Maerki
explicitly
> given list. In this way you end up losing the "future-proofing" of the
> document that is another desired aspect of XSL.
>
> But, one way around these two concerns is to still allow a fox:property
> wherever you would allow a pcl:property, afp:property, etc. The value
> of fox:property would be used whereever a renderer-specific value was
> not specified.
>
> > This may not be a good
> > example but I hope it illustrates what I am trying to achieve.
> >
>
> No, it was an excellent example for discussion.
>
> Glen
Jeremias Maerki
supported yet by
> the renderer. Any thoughts on this / advice for me if I was going to have a
> bash at contributing something along these lines?
Jeremias Maerki
. I haven't investigated that part, yet.
Conclusion:
Using the master-name approach instead of including printer-specific
commands adds flexibility for media and paper tray selection. The only
thing that will be useful is a parameter to FOP and/or an extension
value in XSL-FO which specifies the actualy printer that the print job
is to be generated for so the renderer can use the right set of mapping
rules.
Jeremias Maerki
On 09.05.2006 13:35:11 Chris Bowditch wrote:
> Jeremias Maerki wrote:
>
>
>
> > Conclusion:
> > Using the master-name approach instead of including printer-specific
> > commands adds flexibility for media and paper tray selection. The only
> > thing that
On 09.05.2006 16:04:37 Chris Bowditch wrote:
> Jeremias Maerki wrote:
>
> > On 09.05.2006 13:35:11 Chris Bowditch wrote:
> >>As you've already mentioned in PS there is more than one way of
> >>specifying tray selection. So assuming one particular way (/Media
On 09.05.2006 23:57:24 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > Attention: long post. :-)
> [snip stuff which reminds me on reinventing TeX/DVI]
>
> Using the page master name to map onto output media suggests that
> different page flows could be printed on dif
On 09.05.2006 17:13:40 Chris Bowditch wrote:
> Jeremias Maerki wrote:
>
> > On 09.05.2006 16:04:37 Chris Bowditch wrote:
> >
> >>Jeremias Maerki wrote:
> >>
> >>
> >>>On 09.05.2006 13:35:11 Chris Bowditch wrote:
>
> > This
ners which have
"fixed" positioning.
The metrics now practically match those we retrieve from the font files
ourselves. This results in almost matching output now between PDF, PS
and Java2D (print, TIFF, PNG). Not much left to do here. :-)
Jeremias Maerki
such zero-width lines are device-dependent, their use is not
recommended." It would also be questionable how exactly we would
determine when to use "0" as line width. Probably not the best of ideas.
WDYT?
Jeremias Maerki
The second is probably cleaner but since the change is
backwards-incompatible for any ElementMapping implementation (Barcode4J,
for example), this is not to be taken lightly. I think the first is
easier, should not have any side-effects but feels more like patchwork.
On 15.05.2006 09:27:29 Jerem
d never heard a word back. That's
life. :-)
On 15.05.2006 13:22:29 Chris Bowditch wrote:
> Jeremias Maerki wrote:
>
> > Philippe Drix made me look into why his borders don't show up properly
> > in Acrobat Reader and his printer.
> >
> > He specified bord
eader for TrueType fonts. Ascender and
> descender values were sometimes not in line with FOP's expectations.
> Changed some log output from debug to trace level.
>
> Modified:
> xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/truetype/TTFFile.java
> xmlgraphics/fop/trunk/status.xml
Jeremias Maerki
d as
> AgfaRotisSansSerif). If you change the configuration file 'userconfig.xml
> using
> font names without spaces it doesn't match with the Windows font names. When
> you work with Altova style vision you can't display the preview with the
> correct font.
Jeremias Maerki
tistic tendencies.
So we're free to use the DejaVu fonts. Good news!
On 07.05.2006 13:19:36 Jeremias Maerki wrote:
> Cliff,
>
> I'd like to get some feedback on the license for the DejaVu TrueType
> font set: http://dejavu.sourceforge.net
>
> The DejaVu fonts are d
On 17.05.2006 02:02:52 Manuel Mall wrote:
> 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 i
plied one is probably overkill, too.
Derived from the above, here's what I'm going to do:
- I'll implement the extension attribute on simple-page-master for PCL
so the user can specify the effective paper tray which he has to figure
out himself. The attribute will be optional, of course.
- Nothing else in this area for the moment. If additional requirements
come up I'll deal with that when it's time.
Jeremias Maerki
rk.
>
> Vincent
>
>
> Patrick Paul a écrit :
> > Hello everyone,
> >
> > Great news for me today, I got accepted for the Google Summer of Code to
> > work on the auto table layout.
> >
> > Thank you very much Jeremias for taking the time to apply as a mentor
> > and rank our projects.
Thanks,
Jeremias Maerki
the essay 'Generalized Knuth-Plass Linebreaking Algorithm'. In order
> > to test my ideas in practice, I have written a simple implementation
> > in Java of this approach.
> >
>
> --
> Simon Pepping
> home page: http://www.leverkruid.eu
Jeremias Maerki
On 28.05.2006 20:29:24 Simon Pepping wrote:
> On Wed, May 24, 2006 at 09:47:03PM +0200, Jeremias Maerki wrote:
> > Congratulations to both of you! Both projects got a score of 10 which is
> > the fourth highest score. The ASF got a total of 27 projects. There were
> > other
No idea. Xalan-J hasn't had any changes in their Trunk for 5 weeks. So I
don't know why this suddenly stops working. I guess I'll ask on
gump-general if anyone has an idea what has changed in the last few days.
I'm not even sure how we would have to fix the problem.
On 28.05.2006 20:21:04 Simon Pe
onfirm?
BTW, that's weird, isn't it?
http://svn.apache.org/viewvc/gump/ (404 error)
vs.
http://svn.apache.org/repos/asf/gump/ (ok)
Jeremias Maerki
planning to use this page somewhat as a blog, which
> I'll try to update regularly.
>
> Any comments will be welcome at any time during the project.
>
> Cheers,
> Vincent
>
> [1]
> http://wiki.apache.org/xmlgraphics-fop/GoogleSummerOfCode2006/FloatsImplementationProgress
Jeremias Maerki
t; bug caused by the fact PDFFactory mis-uses the Constructor to
> > PDFFontDescriptor? (looks like StemV and italicAngle arguments are
> > transposed)
> >
> > Chris
>
> Chris,
>
> That's what he pointed out.
>
> Peter
Jeremias Maerki
x27;s fine for now.
Jeremias Maerki
ll try to update regularly.
>
> Any comments will be welcome at any time during the project.
>
> Cheers,
> Vincent
>
> [1]
> http://wiki.apache.org/xmlgraphics-fop/GoogleSummerOfCode2006/FloatsImplementationProgress
Jeremias Maerki
uite itself are also solicited.
Paul Grosso
for the XSL FO SG
- Original Message Ends ----
Jeremias Maerki
ote:
> the bitmap rendering is relatively slow (many small bitmaps). In the end we
> might end up rendering using a BitmapRenderer and only wrapping the whole
> thing in PCL (much like the Windows PCL drivers do). This would be faster
> than creating many small bitmaps.
Jeremias Maerki
cument using a XSLT style sheet. without doing all
> that rendering in between ;)
>
> best regards
>
> stefan ziel
> clan informatica do brasil
Jeremias Maerki
sive, IMO). So?
>
> Thanks,
> Vincent
>
> [1]
> http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200503.mbox/[EMAIL
> PROTECTED]
Jeremias Maerki
th the bottom of the region-body area. The only exception
> would be in "relaxed mode", when a percentage of fullness is introduced.
Vertical justification is certainly something welcome even though it's
an extension for XSL-FO. And at any rate it should be an optionally
enabled feature.
Jeremias Maerki
ion:
> http://svn.apache.org/viewvc?rev=410523&view=rev
>
> I'll update the assertions...
>
> Cheers,
>
> Andreas
Jeremias Maerki
On 05.06.2006 12:23:45 Andreas L Delmelle wrote:
> On Jun 5, 2006, at 10:32, Jeremias Maerki wrote:
>
> > Apologies for that one and thanks for fixing it. I guess I was not
> > looking far enough up in the Ant log.
>
> No problem. Just a lucky coincidence I was follow
from the stored propertylist.
>
> In the meantime, if anyone immediately sees other properties that
> could benefit from this, or has neat ideas related to these matters,
> feel free to share your thoughts.
>
> Later,
>
> Andreas
Jeremias Maerki
>
> URL: http://svn.apache.org/viewvc?rev=412389&view=rev
> Log:
> Add bookmarks even if one of the leaves didn't resolve.
Jeremias Maerki
tter to simply change the code to issue a warning on the log
and ignore the image to match the behaviour of the other output formats.
For the long term, the following will be the right way to go:
http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback
Jeremias Maerki
ATM I've concentrated on the class
> layoutmgr.BreakingAlgorithm, which contains the part of the algorithm
> which is common to page- and line-breaking. It is splitted in parts
> which follow pretty closely those described in "Digital Typography". It
> relies on the following skeleton:{{{
Jeremias Maerki
and static-content if you have to deal with variables
for footnote handling.
Ok, I'm signing off for today. The weather is fine, there's a nice
little wind, not too hot. Perfect day to go sailing. :-)
Jeremias Maerki
go far enough (should store the original Attributes instead
> of the parsed explicit properties; once they're parsed the damage is
> already done, so to speak).
>
>
> Later,
>
> Andreas
Jeremias Maerki
n
> > every Java version.
>
> In fact checkstyle doesn't complain. It seems to be smart enough to
> detect that there is a javadoc for the original version of a redefined
> method. In such cases javadoc copies the definition from the
> super-class, and that's also what Eclipse does in the tooltip. I may put
> @see statements, but I think it doesn't really make sense.
Ah ok, then maybe an older Checkstyle version complained about that. At
least, I had something like that in my mind.
>
> >
> >
> >>* some checkstyle fixes
> >
> >
> > HTH
>
> Updated patch follows.
> Thanks,
> Vincent
Thanks, Vincent. I'll look at it right away.
Jeremias Maerki
values in the
PDF (by mapping DefaultRGB into sRGB). That way I can avoid converting
colors early and still indirectly set up the color transformation from
sRGB to the target CMYK profile.
What I'd like to know is whether you've already done some work in the
CMYK area. Not that we duplicate our efforts.
Jeremias Maerki
o the target device even if it's a
CMYK device (Confirmation from a professional pending, of course). :-)
On 14.06.2006 10:29:21 Jeremias Maerki wrote:
> Max,
>
> I know you're interested in better color handling in FOP. I'm currently
> working on implementing some level
e 1.0 release some time in
July, if possible.
WDYT?
Jeremias Maerki
Do we have someone to represent XML Graphics or one of its subprojects
at ApacheCon US? I won't be going but if anyone wants my material for
the FOP talks, they're available.
Forwarded by Jeremias Maerki
--- Original Message ---
Call for
On 18.06.2006 13:26:00 Manuel Mall wrote:
> 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 ori
On 18.06.2006 22:54:41 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > I just realized we should think about the right moment to release 1.0.
>
> I think 1.0 should implement page masters with different
> body width in the same page sequence.
Ok, if we want that 1.0 w
On 18.06.2006 20:50:31 Simon Pepping wrote:
> On Sun, Jun 18, 2006 at 07:26:00PM +0800, Manuel Mall wrote:
> > On Sunday 18 June 2006 18:53, Jeremias Maerki wrote:
> > > look a little deeper into the issue. I suspect both items will
> > > require substantial changes in
akingAlgorithm has a "force" parameter which is currently set
to true for page breaking. There's also a "threshold". We can probably
play with that first. See LineLayoutManager.findOptimalBreakPoints().
Jeremias Maerki
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:
>
> > > > Or should we use a more
datory keeps?
I think we should see if a single-pass with INFINITE-1 does well enough.
I suspect so, but I'm not sure.
Jeremias Maerki
make sure. :-) It's
pretty unrealistic to expect more than 5 or 10 empty pages before a page
is found with more available BPD.
> Should this strategy not work (for example, we are trying to place a 30cm
> image inside a 20cm-high body), instead of throwing the exception we could
> use the lastTooLong node (which always exists), after removing the "empty
> page" nodes.
Good idea.
Jeremias Maerki
-fop/ImageSupport
It's there for gathering all the requirement on the image library. I'll
bring it up-to-date in a minute. I saw there are a few things I need to
change.
I'm happy to see that you volunteer to work in this area. It's something
I wanted to fix for a long time now but it always had a lower priority. I
envisioned a slightly different direction as you can guess from my
comments but this is still open for discussion.
Jeremias Maerki
ld be used as a line break
> in dire straits, having a penalty value = inf-1 (where inf was the special
> finite value representing infinity). Maybe we could similarly add some
> "soft-keep" extensions?
>
> Regards
> Luca
Jeremias Maerki
ource)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(U
I've updated the ReleasePlanning page. ATM, I've simply changed it to
what I read from this thread. Please, everyone, help sorting out the
details so we can decide where to go.
On 19.06.2006 10:31:15 Jeremias Maerki wrote:
> > So maybe we need a feature freeze and bug fixing
On 19.06.2006 11:35:18 Chris Bowditch wrote:
> Jeremias Maerki wrote:
>
> > On 18.06.2006 13:26:00 Manuel Mall wrote:
>
>
>
> >>
> >>Calling a release 1.0 is IMO quite a significant step which shouldn't
> >>been taken lightly. What we
an eye on the lists as often as possible.
[1] http://xmlgraphics.apache.org/fop/0.92/upgrading.html
On 20.06.2006 23:24:15 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > Ok, if we want that 1.0 won't be out before September.
>
> Too bad. As already mentioned, changing IP
06 11:04:53 Peter B. West wrote:
> On Tue, 2006-06-20 at 12:07 +0200, Luca Furini wrote:
> > Jeremias Maerki wrote:
> >
> > > > On 19.06.2006 15:45:36 Luca Furini wrote:
> > > > It seems to me that the prescribed behaviour requires a keep constraint
> >
On 21.06.2006 16:19:30 Peter B. West wrote:
> On Wed, 2006-06-21 at 12:01 +0200, Jeremias Maerki wrote:
> > Thanks, Peter. I went looking for that reference but wasn't lucky. I
> > gave up after almost 30 minutes. Could you dig up that reference for us?
> >
> > Th
On 21.06.2006 16:34:20 Peter B. West wrote:
> On Wed, 2006-06-21 at 16:24 +0200, Jeremias Maerki wrote:
> > On 21.06.2006 16:19:30 Peter B. West wrote:
> > > On Wed, 2006-06-21 at 12:01 +0200, Jeremias Maerki wrote:
> > > > Thanks, Peter. I went looking for that
ay take some time, especially if I
> > want to make sure that I don't introduce new errors. The implementation
> > of side-floats may suffer from that. That was not the original intent of
> > the SoC project, but I think this would be a benefit for Fop.
> >
> > WDYT?
Please do try to refactor the footnote and before-float stuff out into a
separate class to make the whole design clearer. But don't shift your
focus too much. Some factoring: +1, total refactoring -0.5, keep focus
on your task: +1. ;-)
Jeremias Maerki
but it always had a lower
> > priority. I
> > envisioned a slightly different direction as you can guess from my
> > comments but this is still open for discussion.
>
> I'd rather discuss and bounce ideas back and forth first than writing
> tons of code that needs to be revised. This is not my main project
> either, but it is good to have something to divert myself from time
> to time :)
Good. I think you can reduce the whole thing to the following (it's what
I'd do):
- Split the basic image info from the actualy image data and allow for
different flavors of the same image being present (and in the cache).
1:n dependency from image info to image flavor.
- Allow renderers to request a particular flavor of an image.
This is basically it for the moment from me. It's a little difficult to
concentrate in the hackathon room here at ApacheCon with about 40 people
present. I guess I cannot dive into it more deeply before July 12.
Jeremias Maerki
house with the "optimizing" talk.
Have a good week!
Jeremias Maerki
I've just written to the XSL SG. Hopefully, the question gets answered
this time.
On 22.06.2006 10:40:36 Peter B. West wrote:
> On Wed, 2006-06-21 at 16:50 +0200, Jeremias Maerki wrote:
> > >
> > > Have you tried the Disposition of Comments? I don't know how acce
at least a small fee even for ASF members in the interest of making
it a little cheaper for non-members.
On 04.07.2006 17:24:10 Christian Geisert wrote:
> Jeremias Maerki schrieb:
>
> > I've been approached by Arje Cahn during ApacheCon. He invited me to the
> > yearly Cocoon
ightly below the main
> text baseline. But this scheme for integrating fop/jeuclid
> would instead put the zero's baseline consistent with the
> surrounding text.
>
> Perhaps you're already aware of this, but as a fop user who
> would like to see robust equation support, I thought it
> worth pointing out.
>
> Thanks,
> Ryan
Jeremias Maerki
() so it
really removes the disabled node.
See the attached demo file (You'll need italian hyphenation available to
get the error).
I'll try to fix that tomorrow. If Luca or anyone else has any further comments
on that, I'd appreciate it.
Thanks,
Jeremias Maerki
CH00695663_all_font2.fo
Description: Binary data
; AFAICT there seem to be problems with the percentage resolution in a
> retrieved marker (?) Still have to check whether this is a general
> issue, but all other tests passed, so I consider this one fixed.
>
> Testcase demonstrating the remaining problem will be added shortly.
>
> Later,
>
> Andreas
Jeremias Maerki
lang.Class) in org.apache.xmlgraphics.util.Service cannot be
> applied to (java.lang.Class,boolean)
> [javac] Iterator providers =
> Service.providers(ElementMapping.class, false);
> [javac] ^
Jeremias Maerki
Thanks everyone. I know now which way to go.
On 11.07.2006 20:14:59 Finn Bock wrote:
> Jeremias Maerki wrote:
>
> > One of my clients reported to me that he gets a "Should be first" error
> > message on the log. This happens in (Page)BreakingAlgorithm.removeNode().
&
Hey, that was just a reminder in case it got lost. No hurry.
On 11.07.2006 18:15:45 Andreas L Delmelle wrote:
> On Jul 11, 2006, at 10:33, Jeremias Maerki wrote:
>
> Hi Jeremias,
>
> > Andreas, did you ever add that testcase?
>
> Sorry. Got a bit side-tracked
, but with one big difference compared to table-layout="auto".
> IIRC, CSS mentions this case explicitly: when table-layout="fixed"
> and column-width="auto" then the column-widths are ultimately the
> widths necessary for the cells in the first row. No need to look at
> the whole table, in any case...
>
> Cheers,
>
> Andreas
Jeremias Maerki
1.html
[2] http://lists.w3.org/Archives/Public/xsl-editors/2006JulSep/0003.html
On 10.07.2006 14:21:35 Jeremias Maerki wrote:
> I've just written to the XSL SG. Hopefully, the question gets answered
> this time.
>
> On 22.06.2006 10:40:36 Peter B. West wrote:
> > On
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.
Jeremias Maerki
e keep values. For everyone else, that's just a quick
search and replace in the stylesheet.
On 13.07.2006 15:13:59 Chris Bowditch wrote:
> Jeremias Maerki wrote:
>
> > Fabio Gianetti made a good comment [1]. I answered like this [2]. I'm
> > currently thinking about
Andreas, what about you? Could you make it to the Cocoon GetTogether?
One or two days of Hackathon (discussions, hacking, fun). Anyone else?
Jörg, Chris, Finn, Peter, Vincent maybe?
It would really be good to be at least 3 or 4 FOP people to make the
expenses worthwhile.
Jeremias Maerki
ertyMapping). If that's
correct and usable remains to be seen.
On 13.07.2006 18:20:46 Patrick Paul wrote:
> Thank you for the advice.
>
> I will sum this up on the wiki page.
>
> So if I understand correctly we have to support certain values even if
> they are illegal ?
with a total size of
258 MB is suddenly produced without exceptions using the VM's default
heap settings, never going beyond 26MB heap usage. *g*
Will test some more and then commit later.
On 21.06.2006 23:03:38 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > Ouch, that could expla
te:
> Hi all,
>
> Just a small comment on HashMaps with weak values:
>
> Jeremias Maerki <[EMAIL PROTECTED]> wrote on 07/13/2006 04:43:07 PM:
>
> > Ok, so I changed the WeakHashMap to a HashMap and wrapped the values in
> > WeakReferences. Tadaaa! A PDF wi
27;, and override to return true on the FONode subclasses in
> question, unless anyone objects...
Jeremias Maerki
ack on elements that it does not know about. This schema should
> help users discover which of their elements FOP does not
> recognize. Probably the content of some elements can be constrained
> further. Please, do so if you see such an element. If this schema is a
> good idea, I will document it on the configuration page of the web
> site.
Jeremias Maerki
inks.
>
> There must be a reason for this code but I don't see it. Perhaps this is
> related to some older code which since was removed? Or have I missed
> something? However, if it is ok I'll simplify that in my patch.
>
>
> Vincent
Jeremias Maerki
501 - 600 of 1931 matches
Mail list logo
