Re: PATCH for Arabic/Persian Text, and Bidi-override!

[Jeremias Maerki]

On 08.10.2006 23:01:13 Kia Teymourian wrote:
> Hi all,
> 
> I am working on a patch for Arabic/Persian Text decoration and  
> Implementation of Bidi Algorithm.
> 
> I have some questions about it and writing to you to ask for your 
> assistance,
> could you please answer my questions!
> 
> 1. Can I use java 1.5 or should preferably use 1.4 or JDK 1.3.

Until further notice FOP must compile with JDK 1.3.
See: http://xmlgraphics.apache.org/fop/trunk/compiling.html

> 2. I have a long list of constants, Unicode Arabic Presentation forms. 
> This list will be used, when the algorithm search for
> the correct glyphs forms. I think for the best Performance I should 
> define some static final arrays, and write them directly in the
> class program codes. They are some defined Unicode constants, which I 
> get from the Arabic Unicode definition.
> It is also to put them extern in some Text files, read them from 
> there.   Which form would be the best ?

Whatever is fastest. I think both approaches are fine. Have you looked
at ICU4J? Maybe it already provides the functionality you need. I
haven't checked. At any rate, we've considered the use of ICU4J before.

> 3. I should add one or two new classes, something like 
> ArabicTextHandler.java
> Can I add them to the package org.apache.fop.layoutmgr ? Where is the 
> right package?

Probably org.apache.fop.layoutmgr.inline.

> 4. Can I use some free TTF Fonts in my test cases, they are licensed 
> under GPL.
> I am going to use Persian TTF fonts from  
> http://www.farsiweb.ir/wiki/Persian_fonts
> Is there any license problems?

Yes, the GPL is off-limits for software distributed by the ASF. :-(

See: http://www.apache.org/legal/3party.html

> 5. The writing-mode which is entered in a block or block-container 
> statement has to be known by the TextLayoutManager but is not delivered 
> correctly. TextLayoutManager.addAreas(...) is called from 
> BlockContainerLayoutManager.getNextKnuthElements(...) and 
> BlockManager.getNextKnuthElements(...).
> Why? Could you please write me your comments about the implemented 
> writing-mode!

The writing mode is communicated to child layout managers through the
LayoutContext. See for example:
BlockContainerLayoutManager.createLayoutContext().

Would you mind showing us a short description of your approach to
implementing this? We've had people before implementing in this
direction but it was often a hack and did not fit in the whole picture.
I just want to spare you a late disappointment. Thanks. Some
documentation will be extremely important for us, since the current
team knows just about nothing about Arabic text. For example, we will
not be able to determine if some output is correct or not.

Jeremias Maerki

Re: Including an sRGB color profile?

[Jeremias Maerki]

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 parsed
> and I am now about to create the java.awt.Color object in
> ColorUtil#parseAsRgbIccColor

Cool

> 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 color profiles will be stored in the
Declarations object. You will then have to extend
org.apache.fop.fo.pagination.Declarations with methods for accessing
individual ColorProfiles. The Declarations object is accessible through
the Root object.

> 
> I did bump into the ColorProfile object getting created but I am not sure
> what the best way is to get hold of that object from the parseColorString
> method

You can probably get to the Root object through the PropertyInfo
object: pInfo.getFO().getRoot().

> Any guidances would be appreciated.




Jeremias Maerki

Re: Including an sRGB color profile?

[Jeremias Maerki]

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
> renderers could use the rgb fallback values specified in the rgb-icc
> function. That looks easy enough by extending the Color class that is now
> used to carry the color information through the different layers and make
> that behave as an rgb Color object, except for the pdf renderer which could
> gather the icc parameters from the class instance.

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()).

> Something that is not clear to me in this context is whether cmyk support
> can be sufficiently covered by always relying on icc profiles. That would
> mean either fop should package a cmyk profile or the user should get one
> from somewhere. To be honest, the #CMYK approach, that then generates
> /DeviceCMYK colors seems rather nice (from a users' perspective).

Yes, I agree. I think that's the only point where you have to extend the
Color class to handle basic device-dependant CMYK. Or maybe it is
sufficient to implement a ColorSpace subclass. Actually, that's probably
the better approach though I don't know if it's easier. I still know too
little about all this color handling stuff to have a clear answer here.

> Anyone any thoughts?
> 
> Also - any pointers for me to figure out what it would take to get these
> changes into the fop code base eventually?

That's the easy part. :-) You just create a patch according to:
http://xmlgraphics.apache.org/fop/dev/index.html#patches

We will then review the patch and include it in the repository if
everything is ok.

One nit, though: In case you add new classes while developing this or if
you make extensive changes in some classes we will need an ICLA (and if
appropriate an CCLA) on file with the Apache Software Foundation. More
info here: http://www.apache.org/licenses/#clas

> Thanks,
> 
> Peter
> 
> 
> 
> 
> 
> 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
> > parsed and I am now about to create the java.awt.Color object in
> > ColorUtil#parseAsRgbIccColor
> > 
> > What is not clear to me is how I can get hold of the color-profile
> > information (as in 
> > 
> >  ?
> > 
> > )
> > 
> > 
> > I did bump into the ColorProfile object getting created but I am not sure
> > what the best way is to get hold of that object from the parseColorString
> > method
> > 
> > Any guidances would be appreciated.
> > 
> > Thanks,
> > 
> > Peter
> > 
> > 
> > 
> >  
> > 
> > Peter Coppens wrote:
> >> 
> >> 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 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-profile is really needed or if ICC colors are
> >>> sufficient, I cannot say at this time. In the end, the function needs to
> >>> generate a java.awt.Color (or descendant if necessary). I'm not sure if
> >>> the rgb-icc() function can sufficiently be mapped into FOP's function
> >>> infrastructure because it uses a non-constant number of parameters.
> >>> 
> >>> 2. Internal representation of colors
> >>> 
> >>> Thanks to Max Berger FOP already uses java.awt.Color throughout the
> >>> layout engine so we don't have to worry much anymore how the color
> >>> information is transported to the renderers. However, I can't tell if
> >>> Java's color infrastructure is up to the task of transporting the color
> >>> information as we need it for CMYK support.
> >>> 
> >>> 3. org.apache.fop.image package
> >>> 
> >>> This package is in need of a redesign for various reasons, one of them
> >>> being that it doesn't use RenderedImage/BufferedImage internally to
> >>> represent decoded images. Instead it uses byte arrays with decoded RGB
> >>> data. In order to properly support CMYK not only for JPEGs, the
> >>> refactoring will need to be done if we want a clean solution.
> >>> 
> >>> 4. Improving the renderers to implement CMYK
> >>> 
> 

Re: Including an sRGB color profile?

[Peter Coppens]

>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 converted values rather than the ones the user
specified as first arguments to the rgb-icc function?
-- 
View this message in context: 
http://www.nabble.com/Including-an-sRGB-color-profile--tf1373500.html#a6713134
Sent from the FOP - Dev mailing list archive at Nabble.com.

Re: Including an sRGB color profile?

[Jeremias Maerki]

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 (getRed(), getGreen(), getBlue()).
> 
> Not sureall pretty new for me, but would the get() functions not
> return the profile based converted values rather than the ones the user
> specified as first arguments to the rgb-icc function?


Jeremias Maerki

XSL 1.1 is in Proposed Recommendation phase

[Jeremias Maerki]

Subject says it all.

From the W3C news:
2006-10-06: W3C is pleased to announce the advancement of Extensible
Stylesheet Language (XSL) Version 1.1 to Proposed Recommendation.
Version 1.1 updates and enhances the XSL 1.0 Recommendation for change
marks, indexes, multiple flows, and bookmarks, and extends support for
graphics scaling, markers, and page numbers. The change list since
Candidate Recommendation is available. Comments are welcome through 3
November.

http://www.w3.org/TR/xsl11/

Jeremias Maerki

XSL-FO 2.0 workshop in Heidelberg next week

[Jeremias Maerki]

If anyone has any requirements for XSL-FO 2.0 which I should bring up at
the workshop in Heidelberg next week, please let me know. Deadline
2006-10-16 so I have time to prepare.

Luca, are you going, too? How do you travel?


Jeremias Maerki

DO NOT REPLY [Bug 40694] - Image gets moved into another area even if there is space

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40694


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2006-10-09 02:19 ---
Fop 0.20.x is no longer supported. Please retest your sample with FOP 
0.92beta. Feel free to re-open the bug if your test fails on 0.92beta.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 40695] - FO Basic link not working on line break

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40695


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2006-10-09 02:22 ---
Please state which version of FOP you are using: 0.20.5 or 0.92beta.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 40695] - FO Basic link not working on line break

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40695


[EMAIL PROTECTED] changed:

   What|Removed |Added

Version|all |0.20.4




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: Including an sRGB color profile?

[Peter Coppens]

>> 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 color profiles will be stored in the
>Declarations object. You will then have to extend
>org.apache.fop.fo.pagination.Declarations with methods for accessing
>individual ColorProfiles. The Declarations object is accessible through
>the Root object.

I am struggling with the fact that the Color object is created in the
ColorUtil#parseColorString method which does not have access to the FO tree
(I think). 

I see two approaches. Either the signature of parseColorString has to change
to take an extra argument that gives access to the tree or creating the
java.awt.Color derived class has to be postponed. Perhaps there are other
solutions as well.

At first sight I would think extending parseColorString makes the most
sense, but I am not sure all callers of parseColorString have access to the
tree and I'd rather not see function signature changes ripple up/down
further.

Any thoughts?

Thanks!

Peter

PS Apologies for the 101 nature of my questions - not sure they are actually
suited for this list.
-- 
View this message in context: 
http://www.nabble.com/Including-an-sRGB-color-profile--tf1373500.html#a6714607
Sent from the FOP - Dev mailing list archive at Nabble.com.

DO NOT REPLY [Bug 40695] - FO Basic link not working on line break

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40695


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2006-10-09 02:49 ---
FOP 0.20.x is no longer supported. Please retest your FO on 0.92beta. Please 
free to re-open the bug if your FO fails with 0.92beta.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 40655] - [PATCH] Failure in PNGRenderer when output file name is missing an extension

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40655


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-10-09 03:34 ---
Patch applied in revision 454331. Thanks.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: Including an sRGB color profile?

[Jeremias Maerki]

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.ColorProfile. Something is already there
> >but with TODO flags. The color profiles will be stored in the
> >Declarations object. You will then have to extend
> >org.apache.fop.fo.pagination.Declarations with methods for accessing
> >individual ColorProfiles. The Declarations object is accessible through
> >the Root object.
> 
> I am struggling with the fact that the Color object is created in the
> ColorUtil#parseColorString method which does not have access to the FO tree
> (I think). 

Indeed, ColorUtil.parseColorString() is used in various places in
various contexts. For this to work as needed, every such call has to
have some context information about the ICC profiles available. For
example, the AreaTreeParser should equally be able to build up the color
instances again from the serialized area tree. There, no FO tree is
available. With the switch to use java.awt.Color you have to specify the
color space when instantiating the color.

> I see two approaches. Either the signature of parseColorString has to change
> to take an extra argument that gives access to the tree or creating the
> java.awt.Color derived class has to be postponed. Perhaps there are other
> solutions as well.
> 
> At first sight I would think extending parseColorString makes the most
> sense, but I am not sure all callers of parseColorString have access to the
> tree and I'd rather not see function signature changes ripple up/down
> further.

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. There would be an implementation for the FO
tree context and one for the AreaTreeParser context, maybe some
additional implementation if necessary. But I can see that there will
need to be some extensive changes. I currently don't see a way around
that. But maybe someone else does.

> Any thoughts?
> 
> Thanks!
> 
> Peter
> 
> PS Apologies for the 101 nature of my questions - not sure they are actually
> suited for this list.

No, that's absolutely ok. I prefer having close contact with
contributors because it minimizes the risk of late surprises for both
sides.


Jeremias Maerki

DO NOT REPLY [Bug 40556] - [PATCH] IndexOutOfBoundsException at ListItemLayoutManager.java:495

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40556


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-10-09 03:58 ---
Patch applied, in revision 454338. Thanks.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 40695] - FO Basic link not working on line break

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40695


[EMAIL PROTECTED] changed:

   What|Removed |Added

Version|0.20.4  |0.92




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: Including an sRGB color profile?

[Peter Coppens]

>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. There would be an implementation for the FO
>tree context and one for the AreaTreeParser context, maybe some
>additional implementation if necessary. But I can see that there will
>need to be some extensive changes. I currently don't see a way around
>that. But maybe someone else does.
>


Trying to trim down the amount of code I will have to touch (this is my
first attempt to contribute to an open source project and I'd rather start
as small as possible)

Perhaps the following could work?

(*) I add a second rgb-icc function, rgb-icc-internal or whatever that does
not take an NCNAME for its colorprofile parameter, but the src of the
matching element from the declarations element.
(*) The user specifies rgb-icc (of course) which will always, I hope, be
parsed through a call to [EMAIL PROTECTED] -> ? ->
ColorUtil#parseColorString. The result of this is a class derived from
java.awt.Color which registers rgb replacement values, icc values, color
profile ncname and also the color profile src (setting the src happens in
the new ICCColorFunction#eval method which has access to the fo tree)
(*) If later ColorUtil#colorTOsRGBString is called, the ColorUtil returns an
rgb-icc-internal iso rgb-icc call where relevant (I guess the name should be
changed)
(*) Obviously parsing of rgb-icc-internal will also be added, but at this
stage the map is no longer needed.


Thoughts on (1) this could work (2) you guys would buy into this rather
awkward approach?

Thanks,

Peter
-- 
View this message in context: 
http://www.nabble.com/Including-an-sRGB-color-profile--tf1373500.html#a6716163
Sent from the FOP - Dev mailing list archive at Nabble.com.

DO NOT REPLY [Bug 40442] - [PATCH] percent length not working in font-size for rtf output

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40442


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-10-09 06:07 ---
Patch applied in revision 454369. Thanks.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: Including an sRGB color profile?

[Peter Coppens]

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
might be the best bet then. 

Also the xsl spec says the replacement values are used when the color
profile is not available (not when the renderer does not know how to deal
with it). When the profile can not be loaded, an rgb Color based on the
replacement values can be created and returned.

Leaves the CMYK casenot sure what to do there. I guess converting
device/default cmyk to (device/default?) rgb is also easy so in that case
replacement values are not needed either. That would mean that the
cmyk(c,m,y,k) approach could work just as well as the perhaps more awkward
rgb-icc(r,g,b,#CMYK,c,m,y,k) hack. It does seem necessary to create a CMYK
color space class though (or complete the one in org.apache.fop.util).

Apologies for all the confusion and unclear questions...this is (obviously)
all very new for me and I am far from confident I grasp all the details or
consequences of possible decisions made


Jeremias Maerki-2 wrote:
> 
> 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 (getRed(), getGreen(), getBlue()).
>> 
>> Not sureall pretty new for me, but would the get() functions not
>> return the profile based converted values rather than the ones the user
>> specified as first arguments to the rgb-icc function?
> 
> 
> Jeremias Maerki
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Including-an-sRGB-color-profile--tf1373500.html#a6726105
Sent from the FOP - Dev mailing list archive at Nabble.com.

Re: Including an sRGB color profile?

[Jeremias Maerki]

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 late here and I'm not available tomorrow. Maybe
someone else might jump in and help in the meantime.


On 09.10.2006 23:35:08 Peter Coppens wrote:
> 
> 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
> might be the best bet then. 
> 
> Also the xsl spec says the replacement values are used when the color
> profile is not available (not when the renderer does not know how to deal
> with it). When the profile can not be loaded, an rgb Color based on the
> replacement values can be created and returned.
> 
> Leaves the CMYK casenot sure what to do there. I guess converting
> device/default cmyk to (device/default?) rgb is also easy so in that case
> replacement values are not needed either. That would mean that the
> cmyk(c,m,y,k) approach could work just as well as the perhaps more awkward
> rgb-icc(r,g,b,#CMYK,c,m,y,k) hack. It does seem necessary to create a CMYK
> color space class though (or complete the one in org.apache.fop.util).
> 
> Apologies for all the confusion and unclear questions...this is (obviously)
> all very new for me and I am far from confident I grasp all the details or
> consequences of possible decisions made
> 
> 
> Jeremias Maerki-2 wrote:
> > 
> > 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 (getRed(), getGreen(), getBlue()).
> >> 
> >> Not sureall pretty new for me, but would the get() functions not
> >> return the profile based converted values rather than the ones the user
> >> specified as first arguments to the rgb-icc function?
> > 
> > 
> > Jeremias Maerki


Jeremias Maerki

Re: XSL-FO 2.0 workshop in Heidelberg next week

[J.Pietschmann]

Jeremias Maerki wrote:

If anyone has any requirements for XSL-FO 2.0 which I should bring up at
the workshop in Heidelberg next week, please let me know.


Some rough ideas, unpolished, and without even having had a look at
both 1.1 and the current 2.0 proposals:
- Generalize headers/footers for every block FO, with some control
  of behaviour:
  - render at the start resp. end of each (normal) area generated
by the FO
  - render only at page breaks, not at start of first resp. end
of last area
  - render only at start of first resp. end of last area, not at
page breaks (complement of previous behaviour)
  Needed for the dreaded "continued next page" stuff, which can
  then be used for lists and other blocks too.
- Blocks with multicolumn layout like for body regions (difficult
  to implement if BPD isn't easily determined from external
  constraints, needs probably a memory consuming branch & bound
  algorithm for layout). Needed for newspaper-like and journal
  layouts, for side boxes and such.
- Text floating around areas absolutely positioned on a page.
  This means, among other things, that line areas may be split.
  In multicolumn layouts, the fixed area may affect more than
  one column. Needed for some journal layouts, for focus text
  and images, side boxes and such.
- An element to get the total number of pages in a page sequence
  or for the whole document (instead of formatted page numbers).
  There are probably some generalizations in there, perhaps the
  number of pages which are plastered with normal areas from an
  arbitrary FO. Needed for some legal documents, namely contracts.
- more color models
- Doing something about the "subtotals on this page" and "number
  of foo stuff on this page" problems, preferably without plugging
  a complete spreadsheet language into XSLFO. Perhaps a  with a possibly
  slightly restricted XPath expression, which selects from the
  referenced page. In case of subtotals, the values to be processed
  should probably be in FO properties (XML attrs) in a canonical
  lexical representation instead of using the formatted content. This
  avoids reparsing the formatted, possibly localized content. XSLT can
  easily generate the additional, redundant data.
- Clarify the hyphenation-char stuff. Is it a char or a string? A
  FO property expression or a shorthand with a special syntax?
- Fix the kludge which allows page-number-format="01" to be
  processed according to common expectations. If done properly,
  this may fix some other problems like the problem with
  hyphenation-char above as well.
- Recommendations on metadata, references to appropriate standards
- Recommendations and/or (non-)contracts on how to handle external
  ressources if they are used multiple times (e.g. images in static
  content). Useful to know how the processor may or must not behave
  if the ressource is dynamically generated on access.

More radical thoughts:
- Deprecate both list and table elements and replace by a single
  unified element set for grid layouts. A content flow is a series
  of blocks, which may contain in a blocks, inlines or a grid of other
  blocks.
- Deprecate mixing inlines and blocks :-P
- Invent controls so that blocks can be broken both in IPD and BPD
  for pagination. This may solve the "break wide tables horizontally" as
  well as the "parallel flow text" problems, unless it is already solved
  this way in 1.1
- Automatic page master switching in case of IPD overflow. This is the
  "switch to landscape for wide tables/images" problem. The difference
  to explicitely switching page masters is that some other content
  before/after the wide FO may flow onto the page, thereby avoiding
  unpleasant white areas on the page before and on the last page of the
  wide element.

Please tell me if you need clarifications on any of the points.

J.Pietschmann

Re: XSL-FO 2.0 workshop in Heidelberg next week

[Nicol Bolas]

A few. I do think, when proposing these things, it is important to remember
that XSL-FO is not intended to implement all possible typsetting operations,
that it still needs to remain "easily" implementable.

I guess one question I have is how different should XSL-FO 2.0 be from 1.1?
Should it just be some minor changes/fixes, or are they considering some
pretty substantial changes? Because if it is the latter, I've got some
suggestions with that regard:

* Eliminate entirely the notion of unbounded page lengths/viewports. That
is, browser-like viewing with scrollbars and such. This, among other things,
has the effect of making the viewport stuff unnecessary and substantially
clarifies the specification and any descriptions thereof. The primary
purpose of XSL-FO is for paged media; we already have tools for unpaged
media.

* Seriously reconsider having block-level elements and inline elements be
interleaved. It probably makes FO processor implementation a bit more
difficult. Plus, it's just needless; you can easily wrap that inline stuff
in a block.

* Page specification (simple-page-master) could be made so much more
intuitive. It is far too easy to put a header in the middle of your content
by accident, and while I support that functionality, it should not be the
default.

If it's just minor changes:

* Allow for lists that periodically reverse the left/right (IPD,
technically) positioning of the blocks. Generally, to allow for lists that
alternate one after another which side the content and which side the list
item is on. It would, also, be useful to alter other attributes when doing
this. There is a FO-processor that has an extension to do it, but I forget
its name. This alternation would likewise be reset at every page/region
break.

* In that same vein, similar alternation patters for table row properties
that reset at page/region breaks. This would allow for alternate color
backgrounds, but that always start (wherever they are visible) on a
particular boundary.

* FO 1.1 added the ability to have multiple body regions on a page, and a
flow map to dictate how data flows from one to another. What was not added
were appropriate keeps/breaks to deal with the possibility of switching to a
new region without leaving the page itself. This distinction should be made.

* The ability to specify 2-up/4-up/etc style page generation. This cannot be
done even with FO 1.1's multiple body regions, because one lacks the ability
to have multiple static content regions on a page, as well as where those
regions get placed. Something like a "multiple-page-master" that physically
shrinks several simple-page-masters onto a single page.

* Footnote numbering/indexing per page or region, rather than leaving it up
to the FO document. The "numbering", of course, needs to be flexible and
user-definable (perhaps as a sequence of character possibilities that is
referenced).

* Meta-data needs to be handled in some way. A section, perhaps just after
the page master section, would be ideal.

* Please give us a RELAX NG+Schematron schema for XSL-FO. It would be so
incredibly useful to have such a thing.
-- 
View this message in context: 
http://www.nabble.com/XSL-FO-2.0-workshop-in-Heidelberg-next-week-tf2408511.html#a6727041
Sent from the FOP - Dev mailing list archive at Nabble.com.

Re: PATCH for Arabic/Persian Text, and Bidi-override!

[Manuel Mall]

On Monday 09 October 2006 05:01, Kia Teymourian wrote:
> Hi all,
>
Hi,

Jeremias already responded to you and my comments go in the same 
direction. Firstly, its great that you want to look at this aspect. I 
did investigate support for UAX#14 Unicode compliant line breaking over 
a year ago. I recommend you search the mailing list for UAX#14 and you 
will find the relevant threads.

Joerg contributed some code (never integrated) that implements the line 
breaking table lookup / state machine. That code makes use of Java 
classes created from Unicode data tables. You may want to have a look 
at that as there are possibly things you can reuse (see 
http://people.apache.org/~manuel/fop/linebreak.tar.gz).

BTW, I would place this type of code which basically deals with text 
manipulation in its separate package org.apache.fop.text or 
org.apache.fop.text.unicode.

If you look at text decorations, glyph merging, ligatures it would be 
good if it covers also non arabic languages. For example glyph merging 
applies to some european languages as well (german umlauts, french 
accents, etc.).

Don't hesitate to ask for help on this list. I'll be happy to assist.

> I am working on a patch for Arabic/Persian Text decoration and
> Implementation of Bidi Algorithm.
>
> I have some questions about it and writing to you to ask for your
> assistance,
> could you please answer my questions!
>
> 1. Can I use java 1.5 or should preferably use 1.4 or JDK 1.3.
>
> 2. I have a long list of constants, Unicode Arabic Presentation
> forms. This list will be used, when the algorithm search for
> the correct glyphs forms. I think for the best Performance I should
> define some static final arrays, and write them directly in the
> class program codes. They are some defined Unicode constants, which I
> get from the Arabic Unicode definition.
> It is also to put them extern in some Text files, read them from
> there.   Which form would be the best ?
>
> 3. I should add one or two new classes, something like
> ArabicTextHandler.java
> Can I add them to the package org.apache.fop.layoutmgr ? Where is the
> right package?
>
> 4. Can I use some free TTF Fonts in my test cases, they are licensed
> under GPL.
> I am going to use Persian TTF fonts from
> http://www.farsiweb.ir/wiki/Persian_fonts
> Is there any license problems?
>
> 5. The writing-mode which is entered in a block or block-container
> statement has to be known by the TextLayoutManager but is not
> delivered correctly. TextLayoutManager.addAreas(...) is called from
> BlockContainerLayoutManager.getNextKnuthElements(...) and
> BlockManager.getNextKnuthElements(...).
> Why? Could you please write me your comments about the implemented
> writing-mode!
> Thank you!
>
> best regards,
> Kia Teymourian

Manuel

Re: XSL-FO 2.0 workshop in Heidelberg next week

[Vincent Hennebert]

Jeremias Maerki a écrit :
> If anyone has any requirements for XSL-FO 2.0 which I should bring up at
> the workshop in Heidelberg next week, please let me know. Deadline
> 2006-10-16 so I have time to prepare.

Jörg's comments just reminded me of something I think is missing in the
current spec:
Enable the "compact box" scheme specified in CSS2: if an inline box is
short enough to fit in the margin of the following block box, it is put
in the margin; otherwise, it is transformed into a block box to be put
before the following block box.

That allows to mimic the DT/DD items of HTML:

termthe definition of the term "term". The definition of the term
"term". The definition of the term "term". The definition of the
term "term". The definition of the term "term".

Another term too long to fit in the margin
the definition of the "too long term". The definition of the
"too long term". The definition of the "too long term". The
definition of the "too long term".


Unless I'm wrong, I don't think this is currently possible to do that in
XSL-FO.

Thanks,
Vincent