+1 from me
On 22 April 2014 19:59, Glenn Adams wrote:
> In that case, I will add my +1.
>
> Thanks for the good work Seifeddine and Vincent!
>
>
> On Tue, Apr 22, 2014 at 12:33 PM, Vincent Hennebert
> wrote:
>
>> On 22/04/14 18:25, Glenn Adams wrote:
>>
>>> Are you satisfied with the level of
>From my limited experience posting to PDFBox, they process patches pretty
quickly and post feedback where appropriate promptly too. Dunno if that
eases your concerns Pascal, but that's my 2 cents worth
On Jan 10, 2013 11:02 AM, "Robert Meyer" wrote:
> Ignore my last message. Chris got there firs
+1 for it being an optional dependency.
On Jan 10, 2013 2:45 PM, "Peter Hancock" wrote:
> +1 if usage is restricted to OTF CFF fonts at first.
>
>
> On Thu, Jan 10, 2013 at 2:20 PM, Vincent Hennebert
> wrote:
>
>> +1
>>
>> Vincent
>>
>>
>> On 10/01/13 13:07, Robert Meyer wrote:
>> > Hi all,
>> >
+1 from me
On 23 October 2012 13:25, Clay Leeds wrote:
> +1 from me...
>
> "My religion is simple. My religion is kindness."
> - HH The Dalai Lama of Tibet
>
> On Oct 22, 2012, at 8:04 AM, Peter Hancock
> wrote:
>
> > Hi Glenn,
> >
> > I have just committed to Temp_RoundedCorners to address som
+1
On 12 October 2012 10:40, Peter Hancock wrote:
> Hi,
>
> Luis Benardo and Myself have just done some clean up to the branch
> Temp_RoundedCorners. This branch implements support for 'fox'
> extension properties for specifying borders with rounded corners.
> Please refer to [1] and [2] for d
Ok Matthias, I'll try and take a look at it and compare it to some of the
test cases we have.
On 26 September 2012 20:14, wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=53724
>
> Matthias Reischenbacher changed:
>
>What|Removed |Added
>
> ---
e?:
> - compute and store length as long
> - introduce a tolerance for equals()
> - cast to integer for renderer
> WDYT?
>
> 2012/9/25 mehdi houshmand :
> > While you may be right Pascal, I'm sure this isn't a good example of a
> > legitimate use-case. But the
), that's the reason why the SVG file is a bit odd. Normally I don't
> use
> > , that was only for providing a more compact
> > test case.
> >
> > Thanks again for your help & best regards,
> > Matthias
> >
> >
> > On 24.09.2012 06:14, mehd
Hi,
Sorry for the slow response. What I meant was that you should double check
that your XMLGraphics JAR (lib/xmlgraphics-commons-1.5svn.jar) is inline
with the FOP-trunk version. FOP builds on my machine and GUMP (the
automagical build runner) hasn't thrown any exceptions of late, so it's
most li
Hi All,
I believe I've completed the work on XGC to allow restrictions to the I/O
capabilities, by default, obviously, the mechanisms haven't changed. I've
tried to address some of the suggestions made by the community, Jeremias'
in particular, about the ramifications of changing the APIs and as s
Hi,
Just double check your XGC JAR is the same as the version in trunk, a
commit to the TIFF image system was committed and had a new XGC committed
too, trunk on my computer compiles without issues.
Thanks
Mehdi
On 18 September 2012 00:04, Bonekrusher wrote:
> Hi, I updated to the latest trun
-dev@xmlgraphics.apache.org
> > Cc: priv...@xmlgraphics.apache.org
> > Subject: 1.1 Release (was Vacation)
> >
> > On 05/09/2012 13:55, mehdi houshmand wrote:
> >
> > Hi All,
> >
> > Apart from my initial e-mail there's nothing private in this e-ma
My bad. Just fixed this
On 4 September 2012 10:49, Vincent Hennebert wrote:
> On 03/09/12 09:38, mehdi wrote:
> > Author: mehdi
> > Date: Mon Sep 3 08:38:26 2012
> > New Revision: 1380169
> >
> > URL: http://svn.apache.org/viewvc?rev=1380169&view=rev
> > Log:
> > Amended a couple javadocs and s
werful addition in Java 5.
> In general, I would justify adding a runtime dependency whose size is
> comparable to FOP's size, if there are issues that can't be resolved
> equally well by writing a few lines of code. Or, if you intend to refactor
> FOP's internal data structure
Hi All,
I've come across a yet another concurrency based bug in FOP, this time to
do with how we handle AFP character-sets. The problem in this scenario is
that the CharacterSetBuilders are singletons and their creation wasn't
really intended to be used in a heavily multithreaded system. As such,
Hi Jeremias,
You are correct, I'll fix this as soon as it's convenient.
Mehdi
On 26 July 2012 17:36, Jeremias Maerki wrote:
> When I've looked through the changes made to FOP's public API, I was
> wondering what a SchemaAwareResourceResolver was. First thought was:
> what does that have to do
Glenn,
Is it worth porting these javadoc amendments to the 1.1 branch? I don't
mind doing it if you'd like them in 1.1.
Mehdi
On 23 July 2012 11:21, wrote:
> Author: mehdi
> Date: Mon Jul 23 10:21:23 2012
> New Revision: 1364567
>
> URL: http://svn.apache.org/viewvc?rev=1364567&view=rev
> Log:
familiar with the Apache
> infrastructure but some years ago I updated our own development
> infrastructure (SVN / Jira / Jenkins / Artifactory / Confluence / ...) and
> are currently migrating from svn to git.
>
> On Jul 19, 2012, at 11:39 AM, mehdi houshmand wrote:
>
> > Havi
ybe we should start a new thread for this? We seem to
be hijacking a commit message...
Mehdi
On 19 July 2012 09:14, Chris Bowditch wrote:
> On 18/07/2012 14:06, mehdi houshmand wrote:
>
> Hi Mehdi,
>
> As we've seen this morning, my ineptitude at even basic bureaucracy
>>
As we've seen this morning, my ineptitude at even basic bureaucracy doesn't
really qualify me to show a bias to either side, but I'll give my 2 cents
worth since I am a stakeholder in this debate:
On 18 July 2012 13:17, Vincent Hennebert wrote:
>
> Well, the problem is probably not the lack of
I did create a bugzilla entry (
https://issues.apache.org/bugzilla/show_bug.cgi?id=53563), I just didn't
put the bug number in the commit message, my apologies, I was complacent in
that regard. Is it worth changing the commit message retrospectively to add
the bugzilla entry?
Mehdi
On 18 July 201
Glenn Adams wrote:
>
> On Thu, Jul 5, 2012 at 12:41 AM, mehdi houshmand wrote:
>
>> Hi Chris/Glenn/Anyone else,
>>
>> You say command-line options should override the fop.xconf values, which
>> makes sense. But should not-given command-line options override fop.
ate strictly, so how would a user
expect FOP to behave?
On 4 July 2012 17:26, Chris Bowditch wrote:
> On 04/07/2012 17:15, Glenn Adams wrote:
>
>>
>> On Wed, Jul 4, 2012 at 9:25 AM, mehdi houshmand > med1...@gmail.com>> wrote:
>>
>> On 4 July 2012
t;
> Clay Leeds
> --
> - <http://ourlil.com/>
> My religion is simple. My religion is kindness.
> - HH The 14th Dalai Lama of Tibet
>
>
> On Wed, Jul 4, 2012 at 9:26 AM, Chris Bowditch
> wrote:
> > On 04/07/2012 17:15, Glenn Adams wrote:
> >&
On 4 July 2012 12:32, Vincent Hennebert wrote:
> One thing I forgot to mention: this work deserves its entry in the
> status.xml file, with importance set to ‘high’.
>
> Let me insist on that one. The inconsistency is actually introduced by
> Fop classes. Before the merge there were 14 classes h
Sorry for the spam guys, I didn't realise an svn prop change didn't require
a commit.
On 4 July 2012 11:41, wrote:
> Author: mehdi
> Revision: 1357110
> Modified property: svn:log
>
> Modified: svn:log at Wed Jul 4 10:41:54 2012
>
> --
ter speaking to PH, it didn't seem appropriate to refer to it as a
directory since it could be anything. The javadoc clearly describes the
behaviour of the method, I think this is sufficient for now.
On 4 July 2012 08:38, mehdi houshmand wrote:
>
>
> On 3 July 2012 15:48, Vincent Henn
>
The intention was to provide an interface that covers both use cases, AFP
and everything else, so that we could make the font configuration process a
bit more OOP and a bit less "if (something) do something". Time constraints
howerver...
>
> src/java/org/apache/fop/fonts/FontCo
Thanks guys, that's 5 x +1 and no one in opposition. I'll merge in the
branch imminently and update the docs as appropriate
On 2 July 2012 14:40, Glenn Adams wrote:
>
> On Mon, Jul 2, 2012 at 7:25 AM, mehdi houshmand wrote:
>
>> Ahh I see, ok, thanks Pascal. I think w
with you: it a such branch 1.1 should exist ;-)
>
>
> 2012/7/2 mehdi houshmand :
> > Excuse my ignorance here, but why do any changes to trunk affect 1.1RC*?
> The
> > 1.1 branch has already been defined and voted upon, I don't see how any
> > changes to trunk would aff
encies).
> So, every further RC or final releases are planed to be ma
> 2012/7/2 mehdi houshmand :
> > Hi Pascal,
> >
> > I won't be merging this into anything other than trunk. Sorry, maybe I
> > should have made that more explicit.
> >
> > Mehdi
>
t that the release process start with a 1.1 branch,
> from witch RCx and final release will be tagged, that should allow to
> continue merging branches onto trunk without any interaction on branch
> release.
> WDYT?
>
> 2012/7/2 Chris Bowditch :
> > On 26/06/2012 15:39, mehdi hou
sers the means to
disable and/or restrict those services.
Mehdi
On 26 June 2012 15:57, Glenn Adams wrote:
> On Tue, Jun 26, 2012 at 8:38 AM, mehdi houshmand wrote:
>
>> It means we can get rid of the font-caching and don't have to to worry
>> about performance bu
Sorry, added "[VOTE]" to subject line... My bad
On 26 June 2012 15:38, mehdi houshmand wrote:
> Hi All,
>
>
>
> I think we've got to the stage in the URI unification branch where it's
> ready to be merged into trunk (not into 1.1RC1). I know there have been
Hi All,
I think we've got to the stage in the URI unification branch where it's
ready to be merged into trunk (not into 1.1RC1). I know there have been
proponents against the inclusion of this feature and/or those who are
concerned the wider implications as it means FOP has fewer contingency
met
+1
On 15 June 2012 16:15, Clay Leeds wrote:
> I was going to say that Pascal had a good point, and that it was really up
> to Glenn.
>
> +1 from me
>
> "My religion is simple. My religion is kindness."
> - HH The Dalai Lama of Tibet
>
> On Jun 15, 2012, at 6:00 AM, Pascal Sancho wrote:
>
> > Ok
Yeah fair play on this one, in all honesty I was being lazy this time.
On 15 May 2012 15:42, Glenn Adams wrote:
> Could you file a bug and reference it against this commit? Most commits
> that change code, except perhaps one that is a trivial fix to a immediately
> prior checkin or a cleanup fix
Sorry, I should also say, this doesn't fix a bug. We've just changed the
interpretation of the spec, both ways are valid, but some PTOCA
interpreters need DBCSs to finish on character boundaries
On 11 May 2012 14:42, mehdi houshmand wrote:
> This isn't a significant change, i
This isn't a significant change, it just changes the max TRN size for a
DBCS to 252 rather than 253 for SBCSs. The rest of the patch is just clean
up, I don't think it warrants a bug really...
On 11 May 2012 14:40, Glenn Adams wrote:
> was there a bug filed against which this fix was made? it's
Hi,
I'm sceptical the cost/rewards add up, but since Glenn has volunteered for
all the hard work, then there're no costs and only rewards :)!!
It'll be an onerous task and the usually a thankless one, so I'll address
the latter by saying thanks Glenn!
+1 from me
Mehdi
On 17 April 2012 09:15, C
Hi Craig,
I'll address each of your suggestions inline:
The reason I'm adapting fop-pdf-images to support "merging" PDF images
> into the main PDF content instead of using XObject Forms is that the use
> of lots of PDF XObject Forms seems to cause RIPs and clients to perform
> poorly or run out
Hi Jeremias,
I'll add my comments inline:
>
> First, I'd like to stress that I'm not putting out a veto here. I'm
> just trying to take the position of an advocate to the FOP users who
> might not all follow the development closely.
>
Yeah, I/we do appreciate your concerns, it's important for a
Hi Craig,
My sincerest apologies for not getting round to looking at what you've done
here. I'll try and take a look in the next few days and give it a think,
see if there's anything we can do to help.
Apologies once again,
Mehdi
On 28 March 2012 07:39, Craig Ringer wrote:
> Hi
>
> I've nearl
Hi Glenn,
Firstly, although this is loosely related, can you try to keep the emails
in the thread relevant, this is going to be a verbose thread so we don't
want to add to the confusion. As for the public API, I don't believe
IFPainter is part of the public API, but I'm not sure who does and doesn
Hi Jeremias/Chris,
First thing first; I'll second Jeremias's suggestion and Chris in saying
that this is definitely a major release. The best reason is because we're
purposefully changing behaviour. FOP is currently very flexible in handling
URIs, it has a lot of contingency mechanisms for falling
>
> I wouldn’t bother. Lacking of a proper QA process, we don’t use the
> ‘verified’ and ‘closed’ status and consider that a bug has been handled
> once its status has been changed to ‘fixed’.
>
> Vincent
>
Not sure I agree with you there Vincent. Giving a bug a "closed" status
allows us to perfo
/02/12 15:29, Vincent Hennebert wrote:
> > On 16/02/12 10:23, mehdi houshmand wrote:
> >> Hi,
> >>
> >> I was running o.a.f.intermediate.IFParserTestCase in Eclipse, and
> >> found it extremely frustrating that the schema (xml.xsd) had to be in
> >> th
If I'm not mistaken the r1302518 commit broke compile compatibility with
the Jeremias' PDF-image-plugin trunk which needs to be addressed. It's a
simple change if I'm not mistaken, just to do with how PDFDocument holds
it's version (was an int now an enum o.a.f.pdf.Version), there maybe some
other
se at your leisure.
Mehdi
On 8 March 2012 02:17, Craig Ringer wrote:
> On 08/03/12 04:12, Vincent Hennebert wrote:
>> Just my 2 cents on a particular detail...
>>
>> On 07/03/12 07:51, Craig Ringer wrote:
>>> On 06/03/12 18:49, mehdi houshmand wrote:
>>
&
Hi Craig,
Excellent!!! I think we're making some progress here!
> Ugh. A well-designed RIP should be able to load XObject forms on demand
> and free them under memory pressure. After all, an image is also a
> global resource that can be referenced multiple times across different
> pages (an indi
ntative here, it's not my
intention, but I feel this is would be serious scope creep. I see the
pdf-image-plugin as a plugin that treats PDFs as images, nothing more.
If you want to stitch together PDFs, PDFBox is designed just for that.
Mehdi
On 6 March 2012 10:36, Chris Bowditch wrote:
Seems I didn't forward this one to fop-dev either... My apologies.
-- Forwarded message --
From: mehdi houshmand
Date: 29 February 2012 09:41
Subject: Re: fop-pdf-image and fonts; as requested
To: Craig Ringer
Hi Craig,
We had this exact same problem the last tim
-- Forwarded message --
From: mehdi houshmand
Date: 6 March 2012 10:12
Subject: Fwd: Google Summer of Code
To: fop-dev@xmlgraphics.apache.org
I fat-fingered the reply button instead of reply-to-all... *face-palm*
-- Forwarded message --
From: mehdi houshmand
I fat-fingered the reply button instead of reply-to-all... *face-palm*
-- Forwarded message --
From: mehdi houshmand
Date: 6 March 2012 09:33
Subject: Re: Google Summer of Code
To: Craig Ringer
On 6 March 2012 00:16, Craig Ringer wrote:
> On 03/05/2012 09:35 PM, me
%2Efop-users+total+best+fit
>
> Of course there will be drawbacks, FOP is complex (more complex than it
> should be in my opinion, cleanup / modularization would help) and this is not
> a simple task.
>
>
> Alex Giotis
>
>
> On Mar 5, 2012, at 4:49 PM, mehdi houshmand
delve-in code base, also - probably
more importantly - I can't imagine it would serve as encouragement.
Mehdi
On 5 March 2012 14:36, Glenn Adams wrote:
> I would suggest whittling down the fop bug list, starting from the
> beginning.
>
>
> On Mon, Mar 5, 2012 at 6:35 A
and do the admin, all you
have to do is provide ideas for projects. If you have a wish list or a
list of TODOs that you think a newbie could do for a summer project (I
do appreciate that's quite a big caveat), now's your opportunity.
Mehdi
On 1 March 2012 16:26, mehdi houshmand wrote:
"Google Summer of Code Project"? how does it
> relate to ASF and FOP activities?
>
>
> On Thu, Mar 1, 2012 at 3:50 AM, mehdi houshmand wrote:
>>
>> Hi,
>>
>> We're thinking of submitting a proposal or two to the Google Summer of
>> Code proj
Hi,
We're thinking of submitting a proposal or two to the Google Summer of
Code project and wanted to get some input from the community on ideas.
Once we've got a few proposals I'll create a wiki page and put all the
ideas on there, but for now I just wanted to gauge interest.
In terms of mentori
Hi Guys,
My apologies for the lack of transparency on this issue, but I didn't
actually review the changes you made here, in fact, I barely looked at
what PropertyCache actually does. I had some free time, and added a
bunch of unit tests.
The reason this hasn't been committed yet was because Vinc
Hi Craig,
Just out of curiosity, what issues are you having with the
pdf-image-plugin? I spent quite a lot of time with it and submitted a
patch to Jeremias (not sure if he's committed it). Maybe we could help
you there? We've also got some commits lying around that we're not
happy with per-se bec
Hi Jeremias, I'll address your concerns inline:
> First, I would like to suggest you start with listing relevant code
> portions on the wiki before anything else. Where is what? And what's the
> problem with each case? Right now there are only a few vague pointers
> and an underlying unhappiness
Hi,
I was running o.a.f.intermediate.IFParserTestCase in Eclipse, and
found it extremely frustrating that the schema (xml.xsd) had to be in
the same folder as the test class?!?! Why? It means, if I want to run
said test with the Eclipse Junit Runner, I have to copy it into the
proper directory, ma
Sorry, I should have said, this was an issue spotted by Glenn Adams.
Thanks for flagging it up Glenn!
Mehdi
On 14 February 2012 14:48, wrote:
> Author: mehdi
> Date: Tue Feb 14 14:48:00 2012
> New Revision: 1243963
>
> URL: http://svn.apache.org/viewvc?rev=1243963&view=rev
> Log:
> Enabled ass
Hi Glenn,
I fixed this issue in r1243549, this was a mistake made during the
migration to Junit4 (i.e. my fault). The reason "junit-all" doesn't
invoke these tests is because it runs a regex ("**/*TestCase.java"),
which (rather ironically in this case) catches more of the tests than
the TestSuites
Hi,
As I've said previously, I've been looking at unifying URI resolution,
I've looked at a lot of the code regarding this and from what I can
see FOP uses file access for the following types of files:
1) Input/Output files - by that I mean FO and output, both of which
are many-to-many
2) Resource
This has been amended in r1237610. However just to note, this strictly
speaking shouldn't be a checkstyle error, FOP is Java5 compliant not
Java6, and as such that method isn't deprecated.
On 27 January 2012 17:44, Glenn Adams wrote:
> I notice 4 checkstyle errors have creeped into recent trunk c
ann wrote:
> Am 25.01.2012 15:59, schrieb mehdi houshmand:
>> This would mean deprecating
>> o.a.f.apps.FOUserAgent.setRendererOverride(...) since (if I'm not
>> mistaken) this is legacy code to bind a MIME type to IF output.
>
> AFAIR it was meant as a h
On 27 January 2012 20:17, J.Pietschmann wrote:
> Am 27.01.2012 16:35, schrieb mehdi houshmand:
>> There seem to be an awful lot of static main methods around the fonts
>> and hyphenation packages, I was wondering if anyone had any objections
>> to moving all these methods
and creates the final output format.
> This is used at least in embedding.intermediate.ExampleConcat.java
>
>
> Alexios Giotis
>
>
>
>
>
> On Jan 27, 2012, at 1:23 PM, Chris Bowditch wrote:
>
>> On 25/01/2012 14:59, mehdi houshmand wrote:
>>
>> Hi
Hi,
Another proposal for public consideration:
There seem to be an awful lot of static main methods around the fonts
and hyphenation packages, I was wondering if anyone had any objections
to moving all these methods into classes under a single package i.e.
org.apache.fop.cli.utils. This would inv
I've spent some time looking through the examples and the
documentation above and I think the classes listed below are all the
classes necessary for most the use-cases and thus should be considered
the public API.
org.apache.fop.apps.*
org.apache.fop.fo.FOEventHandler
org.apache.fop.fonts.FontMana
Done in r1235358.
On 24 January 2012 14:47, Chris Bowditch wrote:
> Hi Mehdi,
>
>
> On 24/01/2012 10:02, me...@apache.org wrote:
>
>> Author: mehdi
>> Date: Tue Jan 24 10:02:36 2012
>> New Revision: 1235191
>>
>> URL: http://svn.apache.org/viewvc?rev=1235191&view=rev
>> Log:
>> Corrected ty
This change has been reverted, please see
https://issues.apache.org/bugzilla/show_bug.cgi?id=52513
On 23 January 2012 18:38, Jonathan Levinson
wrote:
> I have no vote, but I’m not happy with the change since it will break our
> RenderServer.jar which is a client-server we use for giving rendering
See https://issues.apache.org/jira/browse/GUMP-167, hopefully it will
be resolved in the next build.
On 23 November 2011 09:41, mehdi houshmand wrote:
> This appears to be failing because Gump doesn't have Mockito in its
> class-path, I think it needs to be added to the Gump Metad
This appears to be failing because Gump doesn't have Mockito in its
class-path, I think it needs to be added to the Gump Metadata
(http://svn.apache.org/repos/asf/gump/metadata/project/xml-fop.xml),
does anyone know how I do this?
Thanks
Mehdi
On 23 November 2011 07:50, Jeremias Maerki wrote:
>
Hi,
I've hopefully provided enough information at the link below, if I've
missed anything, I'd be happy to amend the wiki page.
http://wiki.apache.org/xmlgraphics-fop/HowTo/CreateUnitTests
Mehdi
On 21 November 2011 09:09, Chris Bowditch wrote:
> On 19/11/2011 11:04, meh
Hi Simon,
My apologies, I did float the idea about the layout engine tests and
kept to the suggestions that were given me. As such, creating tests is
exactly the same and the subset of tests run are still configurable
via System properties. The behaviour is the same, the only difference
made is in
Hi Simon,
I can confirm receiving the username and password, thanks for doing
all this so quickly, it's very much appreciated.
Mehdi
On 18 November 2011 11:22, Simon Pepping wrote:
> Mehdi,
>
> The account mehdi has been created. I suppose you received a
> communication with the password. You a
Hi Glenn,
Yeah, JUnit4 doesn't allow one to parametrize test names this is a
known issue. I did spend some time looking into how it would be
possible, see https://issues.apache.org/bugzilla/show_bug.cgi?id=51928.
Hopefully it will be rectified soon.
Mehdi
On 16 November 2011 23:47, Glenn Adams
owditch wrote:
>>
>> Dear FOP committers,
>
> The vote has been running for 6 days now so it's time to sum up the votes.
>>
>> Mehdi has submitted dozens of high quality patches and regularly
>> participates on the mailing lists. Mehdi is already an official
lue for font-family: 'Times New
> 'Roman in "'Times New 'Roman, serif".
>
> -Original Message-
> From: mehdi houshmand [mailto:med1...@gmail.com]
> Sent: Monday, October 24, 2011 3:38 PM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: org.apa
> ******
>
>
> -Original Message-
> From: mehdi houshmand [mailto:med1...@gmail.com]
> Sent: Monday, October 24, 2011 9:28 AM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: org.apache.fop.svg.PDFDoc
Hi Eric,
Could you put up which unit tests are failing. Another user is having
a similar issue.
Thanks
Mehdi
On 24 October 2011 14:05, Eric Douglas wrote:
> Sounds like just what I was looking for! Thanks!
>
> I used the TortoiseSVN to download the trunk but I still haven't figured
> out how
Sorry Eric, I meant to say, this is a developer question, could you
post questions concerning the code on fop-dev in future.
Thanks
Mehdi
On 19 October 2011 14:47, mehdi houshmand wrote:
> Hi Eric,
>
> The renderers of old were removed quite a while ago in commit#989178.
>
>
Width() is not overwritten in
> MultiByteFont, and that therefore MultiByteFont.getDefaultWidth()
> returns the wrong value. Can there be a test that reveals such an
> error?
>
> Simon
>
> On Wed, Sep 28, 2011 at 08:53:26PM +0100, mehdi houshmand wrote:
>> Hi,
>>
>> Th
Hi,
This is my fault, I think this was a merge conflict here, it should be
MultiByteFont.getDefaultWidth().
My apologies.
Mehdi
On 28 September 2011 20:38, Simon Pepping wrote:
> Revision 1175754 introduces a significant findbugs error:
>
> VERY confusing to have methods
> org.apache.fop.fonts
subset the tests from command line based on which targets i select;
>
> On Fri, Sep 23, 2011 at 3:57 PM, mehdi houshmand wrote:
>>
>> Hi Guys,
>>
>> Since there's been overwhelming support for this, I'll throw another
>> thought out there for people t
on the JUnit
> site, and I have no good reason to link to any other guide without
> evaluating in detail. If another member of our community has made
> the transition on another project and can offer advice, or perhaps can
> I point us to useful resources, this would be most welcomed!
&
Hi Guys,
I want to propose an upgrade of our test system to JUnit 4, the
benefits of upgrading can be found on plenty of blogs [1], but I just
wanted to get a feel of what everyone thought? For those that aren't
familiar with JUnit 4, it is backward compatible, so that may
alleviate some migration
Hi Guys,
I was tasked with fixing this issue, and spent some time cleaning up
and testing this area of code. I really don't want to get in the
middle of this but if any one has any questions or wishes to make
amendments, feel free to do so, or suggest improvements and I'll amend
the patch.
https:
gt; Eclipse Helios on Windows XP.
>> I found that Eclipse does come with an ant folder under it's plugin
>> path so I started with the ant.jar from there.
>>
>>
>> -Original Message-
>> From: mehdi houshmand [mailto:med1...@gmail.com]
>> Sent: T
ake sense, but I'm compiling in
> Eclipse Helios on Windows XP.
> I found that Eclipse does come with an ant folder under it's plugin path
> so I started with the ant.jar from there.
>
>
> -Original Message-
> From: mehdi houshmand [mailto:med1...@gmail.com]
>
ose tests do not cover rendering, it
> does include use of fonts.
> Could you send me the "large latin only document" in FO form (preferably
> compressed if large), so I may test it?
> G.
>
> On Tue, Jul 19, 2011 at 7:51 AM, mehdi houshmand wrote:
>>
>> Hi Glenn,
Hi Glenn,
We took a look at the complex scripts support, and a big chunk of the
code-base is in the fonts, and the layout tests don't cover fonts,
rendering etc. What are you finding for end-to-end performance? We
created a large latin only document and found about 50% increase in
time.
Mehdi
On
You'll find it here:
http://ant.apache.org/bindownload.cgi
On 19 July 2011 14:07, mehdi houshmand wrote:
> Hi Eric,
>
> What operating system are you working on? You probably don't need to
> compile ant, there will almost definitely be binaries for your
> operating sy
Hi Eric,
What operating system are you working on? You probably don't need to
compile ant, there will almost definitely be binaries for your
operating system.
Mehdi
On 19 July 2011 13:58, Eric Douglas wrote:
> If I try to compile fop source it says it requires ant.
> If I download the source fo
hole AFP and insert new IMMs
> during the split. I think it's safer this way.
>
> On 12.07.2011 11:12:27 mehdi houshmand wrote:
>> Hi Jeremias,
>>
>> Just to satiate your curiousity, in the modca spec, page 96, it says
>> "A medium map remains in effect until
Hi Jeremias,
Just to satiate your curiousity, in the modca spec, page 96, it says
"A medium map remains in effect until another medium map is selected
or the end of the document is reached.", which means the previous
implementation, storing the lastMediumMap, would be perfectly valid.
Mehdi
On 8
ny.com/help/topic/com.ibm.printers.afpproducts/com.ibm.printers.guidetooutput/c5pu3mst49.htm
>
> "C0" (C - zero) designates a raster character set.
>
> So, CO (C - O) would be wrong.
>
> On 16.05.2011 10:40:00 mehdi houshmand wrote:
>> Hi,
>>
>> Prologue:
>> I am in
1 - 100 of 125 matches
Mail list logo
