DO NOT REPLY [Bug 37114] New: - No error message on illegal/unknown values on a property
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37114. 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=37114 Summary: No error message on illegal/unknown values on a property Product: Fop Version: 1.0dev Platform: All OS/Version: All Status: NEW Severity: minor Priority: P3 Component: fo tree AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] I've written border=solit 1pt into an FO file. When I realized my typo I went looking for an error message but didn't find one. I looked around to fix this myself but didn't find the right spot in reasonable time as I'm concentrating on other stuff right now. I'm posting it here so it doesn't get lost. FOP should notify the user that it has found a value it cannot deal with, especially if this is an enum value. -- 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.
white-space-treatment and white-space-collapse
Hi Fop Devs, FYI, I just posted the following to xsl-editors. Another area in the spec which appears to have some quite mysterious aspects. Hope I haven't made a complete fool out of myself with these questions. Cheers Manuel -Original Message- From: Manuel Mall Sent: Monday, 17 October 2005 19:57 To: '[EMAIL PROTECTED]' Subject: white-space-treatment and white-space-collapse Dear Editors, I am referring to http://lists.w3.org/Archives/Public/xsl-editors/2003JulSep/0012 and the resultant changes in the 1.1 WD and related issues. 1. Under 7.16.8 white-space-treatment it says in the bottom paragraph: quote The white-space-treatment property specifies the treatment during the refinement process of character flow objects... /quote However in the above mentioned post as well as in 4.7.2 of the WD it is made clear that the white-space-treatment property is dealt with during line-building and inline-building. 4.7.2 as well as definitions of the property values also indicate that white-space-treatment is enforced by deleting glyph areas, that is it specifies the treatment of glyph areas not flow objects. I therefore suggest in the interest of clarity to change the sentence to something like: The white-space-treatment property specifies the treatment during line-building and inline-building of glyph areas... 2. A similar issue of clarity exists with respect to the definition of white-space-collapse. There it says in the last paragraph of 7.16.12: quote The overall effect of handling the white-space-treatment and linefeed-treatment properties during refinement and the white-space-collapse property during area tree generation is as follows:... /quote Again it refers to white-space-treatment as being handled during refinement which is in contradiction to the above mentioned post and sections 4.7.2 and 7.16.8 in the WD. However, there is now the problem that both white-space-treatment and white-space-collapse are handled during area tree generation. This leaves, at least in my mind, unclear which one logically happens first. Given that white-space-treatment is defined as a process which deletes glyph areas and white-space-collapse is defined in terms of sibling fo's it seems to me that white-space-collapse has to happen before white-space-treatment but that seems to contradict the intention expressed in the last paragraph of 7.16.12. 3. white-space-treatment is as clearly defined in 4.7.2 applied around line breaks. white-space-collapse however only deals with linefeeds (U+000A) and does not seem to apply around other line breaks. Is that intentional? 4. In 4.7.2 it says in the last paragraph that glyph area merging should only happen on glyph areas with 'matching' traits. No such constraint is put on white-space-treatment (glyph area deletion) nor white-space-collapse in 7.16.12. Is that intentional, that is white space is deleted based only on the Unicode value of the character property/trait independent of any other properties/traits defined on the fo:character/glyph area object involved? Especially white-space-collapse if not happening adjacent to a linefeed seems to have logically more in common with a merge of multiple spaces into one space than a delete of all but one space. 5. In 7.17.3 suppress-at-line-break is says: quote This property applies only to fo:character and determines whether the character's representation shall be suppressed when it would occur adjacent to a formatter-generated line break. /quote I am trying to understand the term formatter-generated line break. If it means line breaks not forced by the user then it doesn't seem to apply here as 4.7.2 explains the use of the suppress-at-line-break property at any line break. If it means any line break then the term formatter-generated is confusing and redundant. In either case it seems it should be removed. Regards Manuel Mall
DO NOT REPLY [Bug 37116] New: - ESC POS Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37116.
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=37116
Summary: ESC POS Renderer
Product: Fop
Version: all
Platform: Other
OS/Version: other
Status: NEW
Severity: enhancement
Priority: P2
Component: awt renderer
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]
Hi all,
i would like to submit this ugly but functional implementation of a renderer
for ESCPOS printers. With correct scale factor it can render against any ESCPOS
printer directly (output stream to the device):
...
Driver driver = new Driver();
OutputStream out= new FileOutputStream(/dev/usb/usbtm0); // the
printer device
OutputStream debug= new FileOutputStream(/tmp/escpos.txt);
driver.setRenderer(new EscPosRenderer(284,new PrintWriter(debug)));
driver.setOutputStream(out);
driver.render(...);
out.close();
...
Please let me know if you need more docs or info.
Andrea.
---Renderer Code--
package eforce.fop.renderer;
/**
* @Author Andrea A. A. Gariboldi
* */
import java.awt.image.Raster;
import java.io.OutputStream;
import java.io.IOException;
import java.io.PrintWriter;
import org.apache.fop.render.awt.AWTRenderer;
/**
* EscPosRenderer converts AWTRenderer output
* to an escpos raster bit image command.
*/
public class EscPosRenderer extends AWTRenderer
{
/**
* Very usefull debug of 0 1 bit maps for
* human beings. Expecially if you put in in
* a file and look at without wrap.
*/
private PrintWriter debug;
public EscPosRenderer()
{
super(null);
this.debug= null;
}
/**
* You will need scale factor to meet your printer
* resolution, example:
*
* EPSON TM-L90 (scaleFactor 284):
* max printable horizontal line = 71mm = 568 dots
* so make a FO document to print a table with solid
* borthers 71mm wide, and find that your scale factor
* is 284. Is not so simple to explain why, you better test
* it, playing with scaleFactor and trying to have your
* table printed as 71mm wide, or better looking at
* debug file, have your table printed as 568 dots wide.
*
*/
public EscPosRenderer(double scaleFactor)
{
super(null);
this.setScaleFactor(scaleFactor);
this.debug= null;
}
public EscPosRenderer(double scaleFactor, PrintWriter debug)
{
super(null);
this.setScaleFactor(scaleFactor);
this.debug= debug;
}
public void stopRenderer(OutputStream out)
throws IOException
{
super.stopRenderer(out);
Raster r= getLastRenderedPage().getData();
double maxY= r.getBounds().getMaxY();
double maxX= r.getBounds().getMaxX();
int h= new Double(r.getBounds().getHeight()).intValue();
int w= new Double(r.getBounds().getWidth()).intValue();
/* convert to black white image (very ugly) */
char[][] imagePixels= new char[h][w];
for (int y=(int)Math.round(r.getBounds().getMinY());ymaxY;y++)
{
for (int x=(int)Math.round(r.getBounds().getMinX());xmaxX;x++)
{
/* rgb values to 0 1 */
if (r.getSample(x,y,0)==255r.getSample(x,y,1)==255r.getSample
(x,y,2)==255)
imagePixels[y][x]= '0';
else
imagePixels[y][x]= '1';
d(imagePixels[y][x]);
}
dln();
}
dln(--);
/* Escpos raster bit image is formed like this x=n*byte(8 bit) y=n*dots
* so we need to convert w from dots to bytes, each byte represents 8
horizontal
* dots, next we fill the end of the line whit nulls (xcorrection).
* The result is an array on bytes to send to the printer.
* */
int paperw= new Double(Math.ceil(new Double(w).doubleValue()/8.0)).intValue
();
int xcorrection= (paperw*8)-w;
byte[] image= new byte[paperw*h];
int cnt= 0,idx=0;
StringBuffer sb= new StringBuffer(8);
// so ugly
for (int y=0;yh;y++)
{
for (int x=0;xw;x++)
{
if (++cnt==8)
{
sb.append(imagePixels[y][x]);
String strb= sb.toString();
d(strb);
int intb= Integer.parseInt(strb,2);
image[idx++]= (byte)chr(intb); //binary string to byte
sb.delete(0,8);
cnt=0;
}
else
sb.append(imagePixels[y][x]);
}
d(|);
for (int c=0;cxcorrection;c++)
if (++cnt==8)
{
sb.append('0');
String strb= sb.toString();
d(strb);
int intb= Integer.parseInt(strb,2);
image[idx++]=
DO NOT REPLY [Bug 37116] - ESC POS Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37116. 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=37116 --- Additional Comments From [EMAIL PROTECTED] 2005-10-17 14:42 --- Created an attachment (id=16716) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16716action=view) Java code Esc Pos renderer -- 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.
Mixing shorthands and normal properties
Assume a block you want to give a 5pt padding and use retain on the before and after edges. fo:block padding=5pt padding-before.conditionality=retain padding-after.conditionality=retain Is it correct behaviour that the before-before and border-after properties override the shorthand, also resetting the width component to zero? The effective padding width for the before and after edges is 0pt ATM. Feels wrong somehow. Any comments? Jeremias Maerki
Re: Mixing shorthands and normal properties
Never mind: http://marc.theaimsgroup.com/?t=11260740931r=1w=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. fo:block padding=5pt padding-before.conditionality=retain padding-after.conditionality=retain Is it correct behaviour that the before-before and border-after properties override the shorthand, also resetting the width component to zero? The effective padding width for the before and after edges is 0pt ATM. Feels wrong somehow. Any comments? Jeremias Maerki Jeremias Maerki
Re: Mixing shorthands and normal properties
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=11260740931r=1w=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. fo:block padding=5pt padding-before.conditionality=retain padding-after.conditionality=retain Is it correct behaviour that the before-before and border-after properties override the shorthand, also resetting the width component to zero? The effective padding width for the before and after edges is 0pt ATM. Feels wrong somehow. Any comments? Jeremias Maerki Jeremias Maerki Jeremias Maerki shorthand-prop-mix.fo Description: Binary data
DO NOT REPLY [Bug 37126] New: - Problem with padding in table
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37126. 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=37126 Summary: Problem with padding in table Product: Fop Version: 1.0dev Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: page-master/layout AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hi, please, have a look at this example. It works fine in FOP 0.20.5. But in FOP 1.0 we get problem. ++ fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=simple margin=100pt page-width=20cm page-height=30cm fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=simple fo:flow flow-name=xsl-region-body fo:table fo:table-column column-width=2cm/ !-- This line indicate that cell must have border and padding! -- fo:table-body border-style=solid padding=30pt fo:table-row fo:table-cell fo:block Must have a padding!!! /fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:flow /fo:page-sequence /fo:root ++ As you see there is no padding. Have you any suggestions how to solve the problem? -- 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 37126] - Problem with padding in table
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37126. 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=37126 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-10-17 19:13 --- Hi, The explanation is that FOP 1.0 is actually more compliant than FOP 0.20.5. The common padding properties *never* apply to any table-related FO other than an fo:table or an fo: table-cell (and only to an fo:table-cell in case the table has border-collapse=collapse). The only solution I see to get the desired effect is that the padding is specified explicitly on the cells themselves. HTH! Andreas -- 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: hyphenation-present and junit-layout
On Sat, Oct 15, 2005 at 10:04:37AM +0200, Andreas L Delmelle wrote: I'm not following here... You will have regression tested code with certain parts not being tested because the optional feature necessary for running those tests smoothly isn't present. If presence of support for hyphenation (the respective patterns) is left to the potential developer, then the testing cycle should take into account that there is the possibility that hyphenation won't be present, and thus skip those hyph-dependent tests with a big warning. The tests won't *fail*. There just isn't enough info/resources available to even perform them. (Failure only becomes applicable if hyphenation is present, and the test can be run in a meaningful way.) That is true indeed. The tests will not fail. My focus is on the Ant target. I want an Ant target to run a predefined set of tests. And if this set includes hyphenation dependent tests, and the required hyphenation support is not available, the Ant target has failed. Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: hyphenation-present and junit-layout
On Oct 17, 2005, at 20:12, Simon Pepping wrote: On Sat, Oct 15, 2005 at 10:04:37AM +0200, Andreas L Delmelle wrote: The tests won't *fail*. There just isn't enough info/resources available to even perform them. (Failure only becomes applicable if hyphenation is present, and the test can be run in a meaningful way.) That is true indeed. The tests will not fail. Ah OK, now I'm following. My focus is on the Ant target. I want an Ant target to run a predefined set of tests. And if this set includes hyphenation dependent tests, and the required hyphenation support is not available, the Ant target has failed. I guess my thinking was along the lines of: - hyphenation is a feature which needs to be explicitly activated by the user (default value for hyphenate=false) - presence of the patterns is also optional (moved to OFFO) So, these two combined seem to clearly outline hyphenation as one aspect of the formatting process, with a right of its own, which can be tested separately/independently from other basic features. This only to further clarify my view in this matter. Cheers, Andreas
Re: svn commit: r320826 - /xmlgraphics/fop/branches/Temp_SpaceResolution/
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 through the details you always find more stuff to look into and to fix. But most of it works now and is available for review while I work on the remaining issues. I assume there is room for optimization here and there. So don't hesitate to jump in and help. The enabled test cases all pass. What I forgot to include in the commit message: I changed from empty block areas to space-before and space-after traits! This caused a lot of changed checks in the test cases. That was a project on its own. :-) But the area trees are much clearer now. That is a lot of code. The result looks very robust. The following case seems to present a problem: ... /fo:block fo:block/ fo:block space-before=10pt background-color=#B5 ... The empty block seems to split the stacking constraint into two constraints, one containing the space-after of the preceding block, and another containing the space-before of the following block. IMHO, this should be a single stacking constraint, case 3d in the spec., section 4.2.5, Stacking Constraints. When the empty block has space-before and/or space-after, it results even in a rule in the output. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
DO NOT REPLY [Bug 37135] New: - [PATCH] Website refactoring
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37135. 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=37135 Summary: [PATCH] Website refactoring Product: Fop Version: all Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: documentation AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] [PATCH] Website refactoring -- 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.
