; From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 11, 2006 6:49 PM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: Including an sRGB color profile?
>
> Without seeing the code, no objections here. It's good to be on the safe
> side by using a synchro
SUE
> > >
> > > To summarize three invocations of ColorUtil#parseColorString give
> > problems
> > >
> > > I went a level further
> > >
> > > 4/ NCNameProperty#getColor
> > > ==> NO FOUserAgent ==> But all callers of getColor seem
se.
Anyone any thoughts?
Thanks,
Peter
> -Original Message-
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 11, 2006 2:29 PM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: Including an sRGB color profile?
>
> ColorUtil, as the nam
No, not as long as a special base URL for that is requested by anybody.
The normal base URL should be used in this case. Too many different base
URLs only causes confusion.
On 11.10.2006 16:48:38 Peter wrote:
> >
> > Would you please try to run URI resolution through
> > FOUserAgent.resolveURI()?
>
> Would you please try to run URI resolution through
> FOUserAgent.resolveURI()? That way we'll have a uniform URI resolution
> everywhere.
>
I am trying, but have a question - does that mean a new base uri config
setting has to be introduced, equivalent to e.g. the fontBaseURL ?
omething that in theory should be able to return the
> FOUserAgent ==> No longer an issue
>
> 9/ BorderProps#valueOf
> ==> NO FOUserAgent ==> ==> But all callers of valueOf (one :)) seem to have
> access to something that in theory should be able to return the FOUserAgent
>
o return the FOUserAgent
==> No longer an issue
> -Original Message-
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 11, 2006 2:05 PM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: Including an sRGB color profile?
>
> Ok for me, as long
Ok for me, as long as we track the outstanding issues.
On 11.10.2006 12:01:19 Peter wrote:
> >
> > Would you please try to run URI resolution through
> > FOUserAgent.resolveURI()? That way we'll have a uniform URI resolution
> > everywhere.
>
> I understand your concern. I will look into it but
gt; case it also makes sense to remove the static colorMap cache.
>
>
> > -Original Message-
> > From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, October 11, 2006 11:33 AM
> > To: fop-dev@xmlgraphics.apache.org
> > Subject: Re: Includ
>
> Would you please try to run URI resolution through
> FOUserAgent.resolveURI()? That way we'll have a uniform URI resolution
> everywhere.
I understand your concern. I will look into it but the issue is that
ColorUtil is really a bunch of static methods that at this stage have no
access to any
.
> -Original Message-
> From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 11, 2006 11:33 AM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: Including an sRGB color profile?
>
> I think the test is fine. Can you tell why the two Color instances
I think the test is fine. Can you tell why the two Color instances
cannot be compared anymore? Do you have to override the equals() method
of your Color subclasses?
On 11.10.2006 11:22:13 Peter wrote:
> I ran the unit tests and I am getting a failure in StandardTestSuite -
> testEquals.
>
> The
On 10.10.2006 21:31:49 Peter Coppens wrote:
>
> I finished(?) working on the somewhat modified items (1), (2) and (4) of
> Jerememias' list.
>
> I plan to clean up to code a bit and then try to submit a patch (there
> should be a first time for everything I guess :))
It's not that difficult. :-
nal Message-
> From: Peter Coppens [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 10, 2006 9:32 PM
> To: fop-dev@xmlgraphics.apache.org
> Subject: Re: Including an sRGB color profile?
>
>
> I finished(?) working on the somewhat modified items (1), (2) and (4) of
> Jerem
I finished(?) working on the somewhat modified items (1), (2) and (4) of
Jerememias' list.
I plan to clean up to code a bit and then try to submit a patch (there
should be a first time for everything I guess :))
Here is an overview of what has been done - probably belongs in the patch as
well, b
Hey, we're all constantly learning here and I didn't find anything
confusing or unclear in your questions. From what I can read between the
lines you're well on your way in the right direction. However, I must
excuse myself until Wednesday before I can continue to help you since
it's already very l
On second thought, having the conversion based on the profile might be the
right thing to do after all. Either the renderer knows how to deal with
color profiles and will do the necessary, or it does not in which case it
will ask the color for its rgb values. The profile based converted values
mig
>I don't think this will go without changing some method signatures.
>Given that not in every context (see AreaTreeParser example above) you
>have the FO tree available. So it may make sense to define a
>ColorContext interface which allows access to the available color
>profiles for the document.
On 09.10.2006 11:49:13 Peter Coppens wrote:
>
> >> What is not clear to me is how I can get hold of the color-profile
> >> information (as in
> >>
> >> ?
> >>
> >> )
>
> >Hmm, yes, I guess that will also have to be implemented. Take a look at
> >org.apache.fop.fo.pagination.C
>> What is not clear to me is how I can get hold of the color-profile
>> information (as in
>>
>> ?
>>
>> )
>Hmm, yes, I guess that will also have to be implemented. Take a look at
>org.apache.fop.fo.pagination.ColorProfile. Something is already there
>but with TODO flags. The
Uh yeah, right. I didn't think about that. No way around subclassing
Color then.
On 09.10.2006 09:54:31 Peter Coppens wrote:
>
>
> >Do you really have to extend the Color class? I think it already
> >provides methods to access the fallback sRGB value which is actually
> >what the FO spec wants (
>Do you really have to extend the Color class? I think it already
>provides methods to access the fallback sRGB value which is actually
>what the FO spec wants (getRed(), getGreen(), getBlue()).
Not sureall pretty new for me, but would the get() functions not
return the profile based convert
On 06.10.2006 15:58:34 Peter Coppens wrote:
>
> Hello again,
>
> Today I played with the FOP PDF package and I seem to making good progress.
>
> That means that besides (1) from below I think I can move forward with (3)
> as well. The idea is to have rgb-icc support for pdf output. All other
>
Sorry for the delay, Peter.
On 05.10.2006 13:40:33 Peter Coppens wrote:
>
> So i have started to look into this today.
>
> Starting at the beginning, I am looking into
> 1. Implementation of the rgb-icc() function.
>
> I have added the necessary code to get the function and its arguments par
Hello again,
Today I played with the FOP PDF package and I seem to making good progress.
That means that besides (1) from below I think I can move forward with (3)
as well. The idea is to have rgb-icc support for pdf output. All other
renderers could use the rgb fallback values specified in the
So i have started to look into this today.
Starting at the beginning, I am looking into
1. Implementation of the rgb-icc() function.
I have added the necessary code to get the function and its arguments parsed
and I am now about to create the java.awt.Color object in
ColorUtil#parseAsRgbIccCo
Jeremias
That is certainly a good start in terms of information to digest.
I'll give it some time to sink in, and I'll try to browse through the code a
bit the coming week to see how familiar I can get with it in that time.
Thanks,
Peter
Jeremias Maerki-2 wrote:
>
> Ok, so here's a rough
Ok, so here's a rough overview what needs to be done. No guarantee for
completeness or accuracy.
1. Implementation of the rgb-icc() function.
See also:
http://www.antennahouse.com/xslfo/axf4-extension.htm#rgb-icc
http://www.renderx.com/reference.html#Color_Specifiers
Whether the #CMYK pseudo-pro
FOP fans,
I could also use cmyk support in fop. My options are to buy some xsl fo
implementation that supports it or trye to contribute to fop (assuming the
community lets me)
Could someone give me a very rough estimate on how much work it would
require, including getting acquainted with the fop
On 31.03.2006 21:48:43 Max Berger wrote:
> I know I have no vote in this, but I do disagree.
Every opinion is always welcome.
> 1) I still believe that PDF is a print medium and should therefore
> default to CMYK colorspace. If supported correctly by software, the
> colors should show up right o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeremias,
Fop-dev,
I know I have no vote in this, but I do disagree.
1) I still believe that PDF is a print medium and should therefore
default to CMYK colorspace. If supported correctly by software, the
colors should show up right on the screen.
2)
On Mar 31, 2006, at 1:09 AM, Jeremias Maerki wrote:
Anyone against me including this color profile (3144 bytes,
uncompressed)
in the org.apache.fop.pdf package?
+1
Clay Leeds
[EMAIL PROTECTED]
My religion is simple. My religion is kindness.
-- HH Dalai Lama of Tibet
32 matches
Mail list logo
