Re: Volunteering to work on FOP development
Jonathan Levinson a écrit : We are an international company, and need to support non-Western documents including Greek, Thai and Chinese, amongst many others. We have technical people at work in every area of the globe. Best Regards, Jonathan S. Levinson -Original Message- From: Simon Pepping [mailto:spepp...@leverkruid.eu] Another area where FOP needs more work is support for non-Western documents. I do not know where the problems are, but it probably does not work right now. Ideally, we would have contributors from regions with such problems. Regards, Simon Hi Jonathan, Regarding non-western documents, in current FOP version: - Latin and Slave alphabets give kind results, since they only depend on fonts charset (my own experience). - Japanese can give expected result (my own experience). - ideographics languages (like Chinese) can give unexpected results regarding line-breakink (from what I read in user-list). - Arabic (and probably all right-to-left writings) cannot be handled correctly by current FOP version: - right to left not implemented (see [1]) - Arabic inner ligatures not handled at all [1] http://xmlgraphics.apache.org/fop/compliance.html#fo-property-writingmode-section HTH, Pascal
Re: Volunteering to work on FOP development
Hi, One area in which FOP needs more work is the compliance with the FO spec, versions 1.0 and 1.1, see http://xmlgraphics.apache.org/fop/compliance.html. For one example: Recently I needed text-align=outside and I would still be happy to have this. Such rather small feature enhancements would give a much better experience using FOP. Best Regards Alex - e-mail: alexanderk...@gmx.net web:www.alexanderkiel.net On Tue, 2009-09-15 at 21:48 +0200, Simon Pepping wrote: On Mon, Sep 14, 2009 at 03:32:25PM -0400, Jonathan Levinson wrote: Hi, My management has asked me to volunteer to help fix FOP bugs and add FOP enhancements. I'm not yet familiar with FOP internals though I've read your design documents. That is good news indeed. Thanks to Intersystems for this contribution. Note that you need to sign an Individual Contributor License Agreement (ICLA), and most conveniently your company needs to sign a Corporate Contributor License Agreement (CCLA), see http://www.apache.org/licenses/#clas, before FOP or any other ASF project can accept your code contributions. One area in which FOP needs more work is the compliance with the FO spec, versions 1.0 and 1.1, see http://xmlgraphics.apache.org/fop/compliance.html. Another area where FOP needs more work is support for non-Western documents. I do not know where the problems are, but it probably does not work right now. Ideally, we would have contributors from regions with such problems. Regards, Simon signature.asc Description: This is a digitally signed message part
Re: Sub Version
Hi Jeremias, I apologize for posting this query to fop-dev and fop-users, will follow as mentioned. Generally for all the bugs we commit, we will write the down the subversion numbers in that bug for the next user. When the next user opens the bug, he will have a direct look into the code. Agree, what you have said, some bugs may not require any changes to source code. I will have a look into the ViewVC URL for the details here onwards. Thanks, Venkat. Jeremias Maerki wrote: Venkat, please don't cross-post on both dev and users mailing lists. This post is clearly development-related so belongs on dev. Thanks. We usually write down the ViewVC URL for the revisions related to a bug. It's pretty much all we can do do to link the changes to the Bugzilla tickets. Of course, not all resolved tickets will also result in a change in SVN. Also, on the other side, we usually mention the bugzilla ID on any change related to a Bugzilla issue. But what we don't do is open a Bugzilla ticket for every change we do. On 15.09.2009 17:01:41 Venkat Reddy wrote: Hi, I couldn't find any subversion numbers on the bugs which are fixed/resolved. I am very new to the FOP users/dev list. If we don't have a column 'subversion' on the bug, will it be nice to write down the subversion number in your comments? so that all the users will verify the code easily for the bugs which are resolved. Thanks, Venkat. Jeremias Maerki
Re: CMYK Colors
On 16.09.2009 14:37:12 Venkat Reddy wrote: Hi, Can someone please explain me the following queries? 1. What is uncalibrated CMYK color space? That refers to device-specific CMYK colors, i.e. the author of the document already has to know which printer a document is printed on and chooses the colors so they look good on that printer. In contrast to that: if you're working in a calibrated color space (established by a color profile), your colors get converted as necessary in downstream processes in order to recreate the color you intended on any printer. Well, that's a simplified explanation and color experts would probably cry out loud, but it's sufficient to explain the difference. 2. What extent the FOP supports this feature? FOP has a proprietary color function that allows to specify device-specific/uncalibrated CMYK colors: http://xmlgraphics.apache.org/fop/trunk/extensions.html#color-functions I just noticed that I didn't commit some changes that would support a #CMYK pseudo-color-profile as other XSL-FO implementations use. I'll have to look into that. It would allow something like this: rgb-icc(1.0,1.0,0.0,#CMYK,0.0,0.0,1.0,0.0) 3. I have got the following fo source code to specify a background color from the CMYK color profile, from which I am able to produce all three differents documents (PDF, AFP, and PS): ?xml version=1.0 encoding=utf-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=demo fo:region-body background-color=rgb-icc(100%,0%,0%,CMYKProfile,0,1,1,0)/ /fo:simple-page-master /fo:layout-master-set fo:declarations fo:color-profile color-profile-name=CMYKProfile src=ECI_Offset_2009/ISOcoated_v2_eci.icc/ /fo:declarations fo:page-sequence master-reference=demo fo:flow flow-name=xsl-region-body fo:block color=rgb-icc(0%,0%,0%,CMYKProfile,0,0,0,1)Demo/fo:block /fo:flow /fo:page-sequence /fo:root I have downloaded this fo file from the bug https://issues.apache.org/bugzilla/show_bug.cgi?id=43705;. Does this means FOP supports CMYK feature? (I have used the FOP Trunk source for this..) This is using calibrated CMYK colors. The fo:color-profile element establishes the ICC color profile under the name CMYKProfile which is then used for output formats that support ICC profiles (just PDF at the moment). In PostScript, for example, this is mapped to the sRGB fallback. 4. There is a class by name 'CMYKColorSpace.java', when will it be used? As the javadocs say, it is used for uncalibrated CMYK color, i.e. for device-specific CMYK color and when there's no ICC color profile. When you use the cmyk() color function, this class is referenced by the ColorExt instance representing the CMYK color resulting from evaluating the cmyk() function. HTH Jeremias Maerki
Re: CMYK Colors
Hi Jeremias, Excellent. Thanks for your quick response. Thanks, Venkat. Jeremias Maerki wrote: On 16.09.2009 14:37:12 Venkat Reddy wrote: Hi, Can someone please explain me the following queries? 1. What is uncalibrated CMYK color space? That refers to device-specific CMYK colors, i.e. the author of the document already has to know which printer a document is printed on and chooses the colors so they look good on that printer. In contrast to that: if you're working in a calibrated color space (established by a color profile), your colors get converted as necessary in downstream processes in order to recreate the color you intended on any printer. Well, that's a simplified explanation and color experts would probably cry out loud, but it's sufficient to explain the difference. 2. What extent the FOP supports this feature? FOP has a proprietary color function that allows to specify device-specific/uncalibrated CMYK colors: http://xmlgraphics.apache.org/fop/trunk/extensions.html#color-functions I just noticed that I didn't commit some changes that would support a #CMYK pseudo-color-profile as other XSL-FO implementations use. I'll have to look into that. It would allow something like this: rgb-icc(1.0,1.0,0.0,#CMYK,0.0,0.0,1.0,0.0) 3. I have got the following fo source code to specify a background color from the CMYK color profile, from which I am able to produce all three differents documents (PDF, AFP, and PS): ?xml version=1.0 encoding=utf-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=demo fo:region-body background-color=rgb-icc(100%,0%,0%,CMYKProfile,0,1,1,0)/ /fo:simple-page-master /fo:layout-master-set fo:declarations fo:color-profile color-profile-name=CMYKProfile src=ECI_Offset_2009/ISOcoated_v2_eci.icc/ /fo:declarations fo:page-sequence master-reference=demo fo:flow flow-name=xsl-region-body fo:block color=rgb-icc(0%,0%,0%,CMYKProfile,0,0,0,1)Demo/fo:block /fo:flow /fo:page-sequence /fo:root I have downloaded this fo file from the bug https://issues.apache.org/bugzilla/show_bug.cgi?id=43705;. Does this means FOP supports CMYK feature? (I have used the FOP Trunk source for this..) This is using calibrated CMYK colors. The fo:color-profile element establishes the ICC color profile under the name CMYKProfile which is then used for output formats that support ICC profiles (just PDF at the moment). In PostScript, for example, this is mapped to the sRGB fallback. 4. There is a class by name 'CMYKColorSpace.java', when will it be used? As the javadocs say, it is used for uncalibrated CMYK color, i.e. for device-specific CMYK color and when there's no ICC color profile. When you use the cmyk() color function, this class is referenced by the ColorExt instance representing the CMYK color resulting from evaluating the cmyk() function. HTH Jeremias Maerki
DO NOT REPLY [Bug 47709] Issue with parsing the 'font' shorthand
https://issues.apache.org/bugzilla/show_bug.cgi?id=47709 --- Comment #1 from Jonathan Levinson levin...@intersystems.com 2009-09-16 10:52:07 PDT --- Created an attachment (id=24277) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24277) Allow case when no font-family is quoted and no comma-separated list of font families Allow case when no font-family is quoted and no comma-separated list of font families. The code in FontShorthandProperty is looking for the beginning of the font-family. If the font-family contains commas then the code works as before. If the font-family begins with a quote the code works as before. There was one case missing - when the code is looking for the beginning of the font family but there are no commas and no quotes. The font-family can be quite complex containing commas, single quoted strings, double quote strings, and strings without quotes but the parsing of this complex expression is taken care of by FontFamilyProperty. All FontShorthandProperty does is look for where the font-family begins. It almost did this correctly (before this patch) when the font-family contained commas or consisted of a quoted string. Now there is the case when the font-family contains no quotes and no commas. However, there is a fly in the ointment. In testing this change (and in testing the previous unchanged code), I added the following test case, which fails in both cases. fo:block font=xx-large/1.4 Arial, 'Times New Roman', sans-serif test:assert property=font-family expected=[Arial, Times New Roman, sans-serif]/ test:assert property=font-size expected=20736mpt/ test:assert property=font-weight expected=400 / test:assert property=font-style expected=NORMAL / test:assert property=line-height.optimum expected=29030mpt / test:assert property=font-variant expected=NORMAL / Test font shorthand /fo:block There seems to be a problem when the quote follows a comma. I will add a patch to font-shorthand-test.fo which demonstrates this problem, and will continue to diagnose the code to see what further problems in the code are causing this problem. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
