purpose of the first release. There will be no guarantees about API
stability or production fitness, in the contrary, there will be big
warning signs. It simply needs to do a few things better than 0.20.5 and
show promise to those who want to continue using FOP in the future and
to those who want to get back to an open source solution because they
are very unhappy with the commercial solutions they were forced to use
because FOP didn't provide certain features they needed or because the
licensing schemes are simply insane for certain use cases.
Jeremias Maerki
ething has changed here since I last looked at it.
> Jeremias?
I have recently implemented Type 1 embedding for those fonts which have
the PFB file specified. Before that all Type 1 fonts were only
referenced, their encoding redefined to WinAnsi and assigned a font key
which is used inside the pages.
Jeremias Maerki
hics/fop/trunk/test/layoutengine/testcases/block_padding_2.xml
> (with props)
> Modified:
> xmlgraphics/fop/trunk/test/layoutengine/disabled-testcases.txt
>
Jeremias Maerki
On 14.09.2005 22:44:07 Simon Pepping wrote:
> On Wed, Sep 14, 2005 at 05:05:37PM +0200, Jeremias Maerki wrote:
> > Can one of the Knuth specialist please review my element list in the new
> > test case below? Thanks.
>
> The element list seems OK to me. The first page also s
t; If so, this should probably be caught as early as possible.
There are no hints in the spec that indicate that the lack of an ends-row
is an error if someone uses starts-row. You can perfectly split a bag
full of cells into tables with only the starts-row or the ends-row
properties. These two properties are simply indicators to the
implementation where to split rows.
Jeremias Maerki
many ...
> otherwise ask again! :-)
Jeremias Maerki
On 15.09.2005 13:35:20 Andreas L Delmelle wrote:
> On Sep 15, 2005, at 13:18, Jeremias Maerki wrote:
>
> > There are no hints in the spec that indicate that the lack of an
> > ends-row
> > is an error if someone uses starts-row. You can perfectly split a bag
> >
receive an error message because I didn't specify an
ends-row="true" on the cell preceding the one I specified a
starts-row="true" on.
On 15.09.2005 15:51:47 Andreas L Delmelle wrote:
> On Sep 15, 2005, at 13:50, Jeremias Maerki wrote:
>
>
> > But it sho
common way of doing it? The spec says only: "The offset ... is
> determined using the font data for the nominal font".
>
> Thanks
>
> Manuel
Jeremias Maerki
AFAICS, no, it doesn't do that, yet.
On 16.09.2005 09:39:55 Manuel Mall wrote:
> Vincent,
>
> does FOray font expose this type of information Jeremias described
> below?
>
> Manuel
> On Fri, 16 Sep 2005 03:36 pm, Jeremias Maerki wrote:
> > It's probabl
s the additional parts
but this can lead to unexpected results as I have seen in one document
already.
Eager to hear your thoughts.
Jeremias Maerki
On 16.09.2005 11:43:37 Andreas L Delmelle wrote:
> On Sep 15, 2005, at 16:05, Jeremias Maerki wrote:
>
> Jeremias,
>
> > Ok, let me then explicitely state that my previous mail contained my
> > own
> > interpretation and no facts. IMO there are certain gaps an
On 16.09.2005 13:09:05 Luca Furini wrote:
> Jeremias Maerki wrote:
>
> > wrap-option is one of those few properties which work in 0.20.5 but are
> > not yet available in FOP Trunk. Luca, what do you think how difficult it
> > would be to implement it at least for
-maintenance/rss.xml
> - Atom:
> http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/atom.xml
>
> == Gump Tracking Only ===
> Produced by Gump version 2.2.
> Gump Run 1916092005, vmgump.apache.org:vmgump-public:1916092005
> Gump E-mail Identifier (unique within run) #23.
>
> --
> Apache Gump
> http://gump.apache.org/ [Instance: vmgump]
Jeremias Maerki
ent="0mm" and
end-indent="0mm" on the table-header, table-footer and table-body to
reset all indents to 0mm. Otherwise, you'll be bitten by inheritance.
See also
http://wiki.apache.org/xmlgraphics-fop/IndentInheritance
Jeremias Maerki
; > scripts) position for each sequence of characters to be rendered.
> >
> > So we may have to introduce the concepts you suggest like
> > actual-baseline-table, dominant-baseline, ... to the fop Layout
> > Managers so they can do their job properly with respect to all this
> > baseline stuff but I am not so sure we need it in the area tree (=
> > interface to the renderers).
> >
> > > Together with bpd, I think that would be enough to find the rest of
> > > the different rectangles.
> > >
> > > I guess it is the same as your suggestion b), but I would rather
> > > stick with the terms used in the spec.
> > >
> > > regards,
> > > finn
> >
> > Cheers
> > Manuel
Jeremias Maerki
uence where refinement takes place.
> TxtRender extends AbstractRender and overloads some methods which process
> model.
> But unlike first approach we have to do much less because LayoutManager gets
> modified formatting objects and returns better result.
>
> We started developing third approach.
>
> Good luck.
Jeremias Maerki
(cc'ing dev@ant.apache.org)
On 16.09.2005 21:23:39 Stefan Bodewig wrote:
> On Fri, 16 Sep 2005, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> > No idea what this is suddenly about. Looks like a permission
> > problem?
>
> No, the file simply doesn't e
On 18.09.2005 13:10:34 Manuel Mall wrote:
> On Fri, 16 Sep 2005 11:41 pm, Jeremias Maerki wrote:
> > I'm not a specialist on typography, yet, but the character wrapping
> > (your option a) sounds definitely like a hack. I've started reading
> > the parts in the spec
On 19.09.2005 10:33:16 Vincent Hennebert wrote:
> BTW, I believe the required renderers for the pre-release are the following:
> * pdf
> * ps
> * awt
> * rtf
> Have I forgotten one?
No.
Jeremias Maerki
t quite clear WRT
> the logic/theory.
>
> Thanks to everyone --especially Jeremias-- for your patience, and for
> the FOTree testsuite, without which I'd probably still be analyzing
> numerous log.debug() messages... :-)
>
> Hope it meets with your approval.
>
> Cheers,
>
> Andreas
Jeremias Maerki
erer (I haven't fixed that as I
> don't know much about PS) and the PDF implementation was slightly
> incorrect (I fixed that but still can't commit ...).
>
> Manuel
Jeremias Maerki
command line under win xp, and even if I don't
> > get any run time exception no output file is created. Launching fop
> > with no parameters, or with wrong parameters (missing files ...) does
> > not create any error: simply, nothing happens.
> >
> > I have compiled fop on two different computers, so I don't think this
> > is a local configuration problem.
> >
> > Hasn't anyone else noticed this?
> >
> > Regards
> > Luca
Jeremias Maerki
On 19.09.2005 23:19:46 Andreas L Delmelle wrote:
> On Sep 19, 2005, at 18:03, Andreas L Delmelle wrote:
>
> > On Sep 19, 2005, at 11:08, Jeremias Maerki wrote:
> >
> >> Looks ok on first glance, though I've got a request: Would you please
> >> consider
PROTECTED]
> > Ignored deferred event for [EMAIL PROTECTED]
> > Ignored deferred event for [EMAIL PROTECTED]
> > ... this continues for quite a while ...
Jeremias Maerki
shmeat:
> http://freshmeat.net/releases/207188/
>
> Can this be used to provide tests for the PDF renderer?
>
> J.Pietschmann
Jeremias Maerki
OP-generated documents in OpenOffice.
> However, I hope this he-said-she-said
> illustrates my correctness concern for the RTF output.
I don't understand what you mean. Probably a foreign language parse
error on my side. :-)
Jeremias Maerki
-*
> property specified.
> To make an even more educated guess, perhaps we could even perform some
> off-hand calculations based on the average font-size, the number of
> blocks, the number of characters of the descendant FOText nodes, the
> content-height for contained images... But this all *without*
> generating the elements. Only minimal communication with the actual
> childLMs in that step, placing the focus on the FONode-elements (= the
> list returned by TableCell.getChildNodes()) and their properties.
>
>
> Does this make any sense?
Hmm. Unless I'm totally mistaken, you're off-course, unfortunately.
Jeremias Maerki
On 21.09.2005 09:52:00 Manuel Mall wrote:
> On Wed, 21 Sep 2005 02:50 pm, Jeremias Maerki wrote:
> > The only
> > reevaluation will happen if we start to implement support for the
> > "changing available IPD" problem, i.e. when the available IPD is
> > d
paces "surrounding" it and what treatment they
> receive. That is the decision if a border/padding is drawn depends
> solely on its conditionality, and the respective "is-first" / "is-last"
> traits on the area in question.
>
> And yes, there is space-start/end stuff in the inline LMs which is
> broken but I would suggest to leave that until the space handling in
> bpd is sorted out.
>
> Manuel
Jeremias Maerki
Messenger should also work but I've only tested vSkype/Festoon
so far.
My IM coordinates:
http://www.jeremias-maerki.ch/contact.html
On 22.09.2005 09:47:09 Manuel Mall wrote:
> On Thu, 22 Sep 2005 03:19 pm, Jeremias Maerki wrote:
> > Hey, I make mistakes. If you guys find anything wron
there are problems. For instance:
>
> ...
> Hi
> Helloworld
> ...
>
> Align doesn't correct.
>
> It's seems that modifying formatting objects before constructing area tree
> model may help to cope with such problems.
>
> > --Original Message-
>
in
> case of txt output it should return TxtHandler.
>
> Good luck.
>
> > -Original Message-
> > From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, September 22, 2005 7:11 PM
> > To: fop-dev@xmlgraphics.apache.org
> > Cc: 'Danila
Are these entries even supposed to work now, or is this still
> to-be-implemented? If so, I might as well take care of that here...
>
> My initial thought is to check for these entries immediately in
> FOUserAgent.setUserConfig(), and if they are present, set them from
> there.
>
> Would that sit right with you all?
> Please respond, I don't like making unilateral decisions :-)
Jeremias Maerki
lized to be re-used if the marked possibility just happens to
> coincide with the actual last page-break).
>
> Am I getting this correctly?
Jeremias Maerki
have to throw out all those old issues by force within
the next few weeks. I'm sure there is a good number of issues that can
be closed and it's good if they are. But be careful with the ones that
help us improve FOP.
BTW, here's something neat:
http://issues.apache.org/bugzilla/chart.cgi?category=-All-&subcategory=-All-&name=976&label0=FOP&line0=304&label1=Batik&line1=176&datefrom=&dateto=&action-wrap=Chart+This+List
Jeremias Maerki
are different.
> Is it correct?
Yes, that's right. In your example the start-indent and end-indent trait
is the same for both blocks. This has to do with the rules established
in 5.3.2 in XSL 1.0.
Jeremias Maerki
On 27.09.2005 09:25:15 Jeremias Maerki wrote:
>
> On 26.09.2005 19:09:59 Sergey Simonchik wrote:
> > Hi,
> >
> > Letters "A" and "B" have same indent from the left edge of page in this
> > example:
> >
> > ...
> > A
> >
On 27.09.2005 16:38:23 Luca Furini wrote:
> Jeremias Maerki wrote:
>
> > It's an interesting idea. However, I suspect this will probably not be
> > necessary. We should be able to make the breaker clever enough to handle
> > this particular case.
>
> Wh
where the
> baseline is but that option is not open to the other values. So, what's
> the point of having "before-edge", "after-edge" as allowed values if
> those baselines are guaranteed not to be defined (and even use them as
> default for e-g and i-f-o)?
>
> Manuel
Jeremias Maerki
nexpected result but I think it's correct. If
anyone could verify that, I'd be grateful.
I'm attaching the PDF output of my local code.
Jeremias Maerki
block_margin_inherit.xml.head.pdf
Description: Binary data
t; top level element, or perhaps some of them wrapped in an element like
> > pagesettings.
>
> No objection from me.
> Anyone with other opinions before I make this alteration?
No, Simon's suggestion is fine.
Jeremias Maerki
newGraphic.setURL(eg.getSrc());
> to string
> newGraphic.setURL(eg.getURL());
> Rtf renderer produced another file "01b.rtf" (in attach too).
>
> File "01b.rtf" seems to be correct whether "01a.rtf" is not.
>
> What do you think about it?
>
>
> Thanks for attention!
Jeremias Maerki
They are in the org.apache.fop.image package. Start by looking at
ImageFactory. They're not in XML Graphics Commons, yet, but will go
there eventually.
On 28.09.2005 23:58:11 Peter Herweg wrote:
> > Jeremias Maerki wrote:
> > I'll look into it tomorrow. Peter's last c
Thanks Manuel!!!
On 28.09.2005 16:48:11 Manuel Mall wrote:
> Jeremias,
>
> looks OK to me although a bit strange but hey...that's the spec.
>
> On Wed, 28 Sep 2005 10:00 pm, Jeremias Maerki wrote:
> > I've just stumbled over the testcase block_margin_inherit whi
as soon as I have SVN access again.
Jeremias Maerki
n.
Yes, they are. We've already achieved one of the major goals: To
bring FOP out of its stagnation and make it more interesting for people
to jump in and help again. FOP's gona live! :-)
Jeremias Maerki
0 p=0 for the break possibility
>
> glue w=-10pt y=0 z=0
>
> box w=0
> penalty w=0 p=INF
> glue w=10pt y=0 z=0
>
> box w=lh for second block
>
> * Example 8
>
> The space-before of the block with "second line" is conditional, and
> therefore is suppressed.
>
> My element list is (case 'All spaces are conditional'):
>
> box w=lh for first line
>
> aux glue w=6pt y=0 z=0
>
> box w=lh for second line
>
> Regards, Simon
>
> --
> Simon Pepping
> home page: http://www.leverkruid.nl
Jeremias Maerki
Ah, so we need to define first, what we really want to expect. :-) Does
the spec say anything about the expected behaviour?
On 02.10.2005 00:57:07 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > On 27.09.2005 16:38:23 Luca Furini wrote:
> [the usual layout oscillation/converg
ies the half-leading trait
> becomes a space-before/after specifier on the line area and therefore
> becomes part of the space resolution algorithm. I assume negative
> values are OK in that case although I am not sure?
>
> Manuel
Jeremias Maerki
ter when I have
some air again.
On 30.09.2005 18:02:20 Sergey Simonchik wrote:
> Did you meet any difficulties?
>
>
> -----Original Message-
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 29, 2005 12:33 AM
> To: fop-dev@xmlgraphics.apache.org
&
L you'll get a proper error message in the
maintenance branch and in the trunk. In the bug reporter's case however
the stylesheet produced non-wellformed output (the XML started with text
after the XML header). I've fixed the trunk to provide better error
messages.
Jeremias Maerki
ue w=10pt y=0 z=0
>
> penalty w=0 p=0 for the break possibility
>
> glue w=-10pt y=0 z=0
>
> box w=0
> penalty w=0 p=INF
> glue w=10pt y=0 z=0
>
> box w=lh for second block
Agreed.
> * Example 8
>
> The space-before of the block with "second line" is conditional, and
> therefore is suppressed.
>
> My element list is (case 'All spaces are conditional'):
>
> box w=lh for first line
>
> aux glue w=6pt y=0 z=0
>
> box w=lh for second line
Agreed.
In example 9 the reasoning was wrong.
Thanks a lot, Simon, for going through all this!
Jeremias Maerki
look at this more closely this week. For the moment I
ignore spaces and conditional lengths surrounging a table. So I'll come
back to this later. As my next step I'll review my code and will upload
my changes in a temporary branch. Starting from there I'll jump into
handling tables.
Jeremias Maerki
breaking it is not
> needed by the TableLM and its child LMs. Am I correct?
Jeremias Maerki
of the
> suggested solutions may be contentious.
>
> Manuel
Jeremias Maerki
d
precedence of this space." I don't read any restriction to only the
first and last generated area of an FO for spaces out of this.
Once again we probably hit a flaw in the spec. AltSoft repeats the
space-before on every page, XEP does not. And no changes to the text in
XSL 1.1 WD. :-(
I think we should start a Wiki page listing all these bloody flaws in
the spec for everyone to see.
Jeremias Maerki
On 05.10.2005 09:46:18 Manuel Mall wrote:
> While I am at it (this whole alignment stuff I mean) we may as well do
> it properly. This would include support for the "script" property. The
> allowed values for script are defined for example here:
> http://www.unicode.org/iso15924/iso15924-codes.htm
Patrick,
what's the status of your website refactoring? This is getting more and
more important. Would you please wrap up everything you've done so far
in a patch and post it? It doesn't need to be perfect, I can do the rest.
Thanks a lot!
Jeremias Maerki
esolution code. Therefore, I'm afraid I can't
provide a testcase for you to easily reproduce. Makes me wonder if it
were very difficult to create JUnit test cases just testing the Knuth
algorithm...
Jeremias Maerki
It's easy after all:
http://svn.apache.org/viewcvs?rev=295059&view=rev
On 05.10.2005 17:01:23 Jeremias Maerki wrote:
> Makes me wonder if it
> were very difficult to create JUnit test cases just testing the Knuth
> algorithm...
Jeremias Maerki
yone
prefers that I should not use them.
On 05.10.2005 22:16:11 Simon Pepping wrote:
> I have never really understood the role of the aux flag on the
> elements. Is it only for the addAreas phase, or does it also play a
> role in the breaker algorithm?
Jeremias Maerki
On 05.10.2005 20:32:53 Simon Pepping wrote:
> On Wed, Oct 05, 2005 at 09:54:17AM +0200, Jeremias Maerki wrote:
> >
> > On 05.10.2005 09:07:36 Finn Bock wrote:
> > > So for inlines we get
> > >
> > > xxx xx xxx xx xxx x xxx iii i
> > >
ce
> character is dropped if the immediately preceding flow object is a
> space character. I would read this as to mean NOT to collapse across
> the boundaries of a fo:inline (FWIW - neither RenderX nor AntennaHouse
> seem to collapse across fo:inline boundaries) although it hinges
That helps a lot. Thanks for looking it up! Yes, Karen was a "Fopper",
and a good one. Now, the only thing left is to fix the bug. :-)
On 06.10.2005 10:23:49 Manuel Mall wrote:
> On Thu, 6 Oct 2005 03:44 pm, Jeremias Maerki wrote:
> > What I write next should be consumed with c
>
> In general, the restarting method is quite a critical phase: we are
> "resurrecting" a node which was not very good, and maybe not all the
> information stored inside it is always correct.
>
> Regards
> Luca
Jeremias Maerki
e is some possible refactoring of this piece of code.
>
> Regards
> Luca
Jeremias Maerki
mail address in
MailAlias.txt in the comitters repository, so Apache people can identify
you if you don't send mail with your @apache address. Of course, there
are lots of other little things you'll find out in time.
If you have any further questions, you know where to reach me. :-)
Jeremias Maerki
> inexperience with the overall FOP software base, it is actually likely
> that there are some unexpected regressions.
>
> Please don't hesitate to 'scream' if you see or notice something you
> feel is wrong or inappropriate or could be coded better or ...
>
> Manuel
Jeremias Maerki
area and is basically the same as fo:wrapper.
>
> I still wonder: creating no line breaks at all should be
> significantly easier than creating breaks...
>
> J.Pietschmann
Jeremias Maerki
quot;follow" or the second halfLeading
becoming space-after could be incremented by 1 mpt.
Thanks,
Jeremias Maerki
ate to the allocation rectangles
defines in 4.2.3. It includes space-before and space-after, so cursor
advancement still works, now that the empty space areas are not
generated anymore (at least in my local code).
Jeremias Maerki
I considered that but decided not to do that because too many such
methods could be a potential source for confusion.
On 10.10.2005 17:33:31 Manuel Mall wrote:
> On Mon, 10 Oct 2005 09:22 pm, Jeremias Maerki wrote:
> > Manuel recently introduced the space-before and space-after
: alpha/preview release only!
On 12.10.2005 20:16:43 David Abrahams wrote:
>
> As FOP is my only hope for a viable open-source alternative path to
> PDF, I have been eagerly anticipating your next release. Can anyone
> give me a sense of how close (or far off) that might be?
Jeremias Maerki
got tired of paying large sums of money for
> crappy systems and decided to create my own document production system. Now
> it produces text, PDF, HTML, and WordML output, all with open-source tools
> (FOP and Saxon).
>
> Jay Bryant
> Bryant Communication Services
>
> - Origi
take a stab? No knowledge about FOP internals needed.
Jeremias Maerki
aywood
>
>
>
> -Original Message-
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 13, 2005 4:39 PM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Volunteer wanted - disabled-testcases.txt in XML
>
>
> I've had a idea, hopefu
rev=320826&view=rev
> Log:
> Temporary branch for the space resolution work
>
> Added:
> xmlgraphics/fop/branches/Temp_SpaceResolution/
> - copied from r320825, xmlgraphics/fop/trunk/
Jeremias Maerki
t possible to change my registered
> email to [EMAIL PROTECTED] to [EMAIL PROTECTED], as I can't get to
> the work email from home.
>
> Thanks
> Mark Gaywood
>
>
>
> -Original Message-
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
> Sen
Good catch!
On 14.10.2005 20:35:17 Simon Pepping wrote:
>
> ...
>
>
>
>
>
>
>
>
> Should the classpath not contain libs-build-classpath instead of
> libs-run-classpath, so that fop.jar (and fop
ng SVN and create patches as described in:
http://xmlgraphics.apache.org/fop/dev/#patches
and
http://xmlgraphics.apache.org/fop/dev/tools.html#patches
and submit them using Bugzilla as Clay already told you.
Jeremias Maerki
fter edges is "0pt"
ATM. Feels wrong somehow. Any comments?
Jeremias Maerki
Never mind:
http://marc.theaimsgroup.com/?t=11260740931&r=1&w=2
On 17.10.2005 15:30:11 Jeremias Maerki wrote:
> Assume a block you want to give a 5pt padding and use "retain" on the
> before and after edges.
>
> padding-after.conditionality="retain"
Anyway, running the attached FO file through a number of FO
implementations does not produce consistent output. Sigh.
On 17.10.2005 15:40:58 Jeremias Maerki wrote:
> Never mind:
> http://marc.theaimsgroup.com/?t=11260740931&r=1&w=2
>
> On 17.10.2005 15:30:11 Jeremias Maer
ver
and handled as needed. I'll document this with a test case.
On 17.10.2005 20:24:43 Simon Pepping wrote:
> On Thu, Oct 13, 2005 at 08:23:50PM +0200, Jeremias Maerki wrote:
> > I finally uploaded my space resolution work so far. It's still not
> > finished. When you go
alysis of how hard this would
> be to fix, as well as suggestions on how to fix it. There are some other
> potential solutions to the wavering clip issue, although I think the above
> is
> by far the cleanest (and hence most desirable) of them.
Jeremias Maerki
days for the new "refactored" website.
>
> If anyone has other requests or ideas for the new website I would be
> glad to hear about them.
>
> Have a nice day everyone.
>
> Patrick Paul
Jeremias Maerki
ally would appreciate any comments, different views,
> clarifications, ... on what has been written so far.
>
> Cheers
>
> Manuel
Jeremias Maerki
Thanks, I'll look into it tomorrow and will get back to you when I have
a good idea what's happening.
On 18.10.2005 22:58:59 thomas.deweese wrote:
> Hi Jeremias,
>
> Jeremias Maerki <[EMAIL PROTECTED]> wrote on 10/18/2005 04:51:00 PM:
>
> > I recently cleane
sabled-testcases.txt) are you envisioning a single xml
> replacement or one xml for each testcase?
>
> Mark
>
> -Original Message-
>
> From: Jeremias Maerki [*mailto:[EMAIL PROTECTED]<[EMAIL PROTECTED]>]
>
>
> Sent: 15 October 2005 07:52
>
> To
On 19.10.2005 03:45:33 Manuel Mall wrote:
> On Wed, 19 Oct 2005 05:44 am, Jeremias Maerki wrote:
> > I've started to comment on the individual issues you listed and only
> > when I got to the examples I realized there must be something wrong.
> > You place the white
"
> of the order of the number of letter spaces, as the adjustment is rounded
> up to the nearest millipoint and is applied to all the letter spaces in a
> line. Having distinct text areas for each word, we could correct this
> error setting appropriately each area ipd.
>
> Regards
> Luca
Jeremias Maerki
On 19.10.2005 10:57:36 Manuel Mall wrote:
> On Wed, 19 Oct 2005 04:34 pm, Jeremias Maerki wrote:
> > If we can reliably find out which characters are spaces and we know
> > their widths, then we can fall back to the behaviour as in FOP 0.20.5
> > just advancing the cursor
robably do right now is clean up a few LM since I've only
commented older code passages dealing with spaces.
http://wiki.apache.org/xmlgraphics-fop/SpaceResolution
Jeremias Maerki
Exactly.
On 19.10.2005 17:11:25 Luca Furini wrote:
> Jeremias Maerki wrote:
>
> > I'd prefer to make the area tree more detailed and the renderers
> > simpler.
> >
> > Maybe we could use a trick to minimize the memory increase by creating
> > an addi
et to check an SVG with clipping inside
an FO document. So far I've only tested SVG with the PDFTranscoder.
In addition to that there was a problem with state tracking which I
solved using the new PDFContext class.
Feedback welcome.
On 18.10.2005 22:58:59 thomas.deweese wrote:
> Hi Jeremias
gt;}
>If isLast, then the edge of the reference area is at the
>end. Should then the resolution not be applied to the reverse
>of secondPart and secondPartLengths?
>
> Regards, Simon
>
> On Thu, Oct 13, 2005 at 08:23:50PM +0200, Jeremias Maerki wrote:
> >
On 20.10.2005 13:38:00 thomas.deweese wrote:
> Hi Jeremias,
>
> Jeremias Maerki <[EMAIL PROTECTED]> wrote on 10/19/2005 12:37:56 PM:
>
> > I see the problem now and I think I found a fix:
> > http://svn.apache.org/viewcvs?rev=326600&view=rev
> >
>
Both problems should by fixed now, as well as another problem with hard
breaks I found while writing the tests.
http://svn.apache.org/viewcvs?rev=326900&view=rev
On 20.10.2005 10:06:02 Jeremias Maerki wrote:
> Both are bugs. Thanks for finding them. I'm currently working on
> t
de.hyp.
> Can you point me in the direction of them?
>
> Mark
>
> On 19/10/05, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> >
> > A single XML file as I showed it in my first post. That's more easily
> > processed later when we put this informati
101 - 200 of 1931 matches
Mail list logo
