You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Paul Wellner Bou <pa...@purecodes.org> on 2009/04/07 13:55:12 UTC

Strange entity behaviour: Omitting last character

Hello,

again, I have a problem with the entities. I saw last time, that it is 
not possible to prevent entities from beeing replaced with their real value.

So why are single quotes ' within attributes replaced with their entity? 
Can I prevent them from beeing replaced?

And why is batik omitting the last character if it has to do something 
with entities? For example:

* If I try to set an attribute to &#xFC; (I did that before I knew that 
all entities are replaced every time), As result I get: &amp;#xFC. The & 
is replaced with it's entity, this is ok, but the semicolon disappeared.

* If I have single quotes in attribute values (Adobe Illustrator seems 
to do this writing the font names), those single quotes are replaced 
with their entity &apos; and the last character of the string within the 
  single quotes disappears:

	Original: font-family="'ArialNarrow-Bold'"
	Batik written: font-family="&apos;ArialNarrow-Bol&apos;"

I am using Batik-1.8pre. Is this a known bug?

Regards
Paul.

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

Re: Strange entity behaviour: Omitting last character

Posted by Cameron McCormack <ca...@mcc.id.au>.
Cameron McCormack:
> > Can you submit a small, standalone program that demonstrates the
> > problem?

Paul Wellner Bou:
> Of course. The SVG:

Thanks.

> I know that it is technically correct replacing it. But why it should?  
> It may have a reason why someone wants it replaced or not. And if there  
> is no need to replace something, I think it shouldn't do it. Or it  
> should be at least configurable.

Yes there’s no reason to.  I just committed a change that serialises
apostrophes as a single character instead of using the entity.

  http://svn.apache.org/viewvc?view=rev&revision=763473

Paul Wellner Bou:
> > > And why is batik omitting the last character if it has to do 
> > > something  with entities? For example:

Cameron McCormack:
> > I don’t think that’s a known bug, no, but it does look like a bug.  As
> > above, can you provide a test case?

Paul Wellner Bou:
> Regarding this I found my error. Not on the batik side. I implemented my  
> own java.io.writer and I catched the string in the buffer using new  
> String(cbuf).substring(off, len) and not String.valueOf(cbuf, off, len);  
> in the overriding write(char[] cbuf, int off, int len) method. Sorry.

OK.

Thanks,

Cameron

-- 
Cameron McCormack ≝ http://mcc.id.au/

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

Re: Strange entity behaviour: Omitting last character

Posted by Paul Wellner Bou <pa...@purecodes.org>.
Hi,

Cameron McCormack wrote:
> Hi Paul.
> 
> Paul Wellner Bou:
>> So why are single quotes ' within attributes replaced with their entity?  
>> Can I prevent them from beeing replaced?
> 
> I doubt that you can prevent them from being replaced without modifying
> Batik.  As with the issue you raised earlier, it is perfectly fine for
> an XML serialisation to use numeric character references and entity
> references like this (i.e., it’s well formed XML).
> 
> In the example below, it’s true that the apostrophes need not be
> replaced with entities inside double-quoted attributes.  I’m not sure if
> the serialisation code sometimes uses double-quoted attributes and
> sometimes single-quoted attributes; if it does, then it may use &apos;
> unconditionally just because it is simpler to do so.  But if it’s usign
> double-quoted attributes all the time, then I agree it’s better if it
> didn’t use &apos;.
> 
> Can you submit a small, standalone program that demonstrates the
> problem?

Of course. The SVG:

<?xml version="1.0"?>
<!DOCTYPE svg PUBLIC '-//W3C//DTD SVG 1.1//EN'
           'http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd'>
	<text font-size="8" font-family="'ArialNarrow-Bold'"">Text</text>
</svg>

The Java Code:

import java.io.File;
import java.io.IOException;
import java.io.OutputStreamWriter;

import org.apache.batik.dom.svg.SAXSVGDocumentFactory;
import org.apache.batik.svggen.SVGGraphics2D;
import org.apache.batik.util.XMLResourceDescriptor;
import org.w3c.dom.Document;

public class BatikTest
{
   public static void main(String[] args)
   {
     try
     {
       File sourcefile= new File("test.svg");
       String parser= XMLResourceDescriptor.getXMLParserClassName();
       SAXSVGDocumentFactory f= new SAXSVGDocumentFactory(parser);
       String uri= sourcefile.toURI().toString();
       Document doc= f.createDocument(uri);

       OutputStreamWriter osw = new OutputStreamWriter(System.out, "UTF-8");
       SVGGraphics2D svgGenerator = new SVGGraphics2D(doc);
       svgGenerator.stream(doc.getDocumentElement(), osw);
       osw.close();
     }
     catch(IOException e)
     {
       e.printStackTrace();
     }
   }
}

I know that it is technically correct replacing it. But why it should? 
It may have a reason why someone wants it replaced or not. And if there 
is no need to replace something, I think it shouldn't do it. Or it 
should be at least configurable.

>> And why is batik omitting the last character if it has to do something  
>> with entities? For example:
 >
> I don’t think that’s a known bug, no, but it does look like a bug.  As
> above, can you provide a test case?

Regarding this I found my error. Not on the batik side. I implemented my 
own java.io.writer and I catched the string in the buffer using new 
String(cbuf).substring(off, len) and not String.valueOf(cbuf, off, len); 
in the overriding write(char[] cbuf, int off, int len) method. Sorry.

Regards
Paul.

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

Re: Strange entity behaviour: Omitting last character

Posted by Cameron McCormack <ca...@mcc.id.au>.
Hi Paul.

Paul Wellner Bou:
> So why are single quotes ' within attributes replaced with their entity?  
> Can I prevent them from beeing replaced?

I doubt that you can prevent them from being replaced without modifying
Batik.  As with the issue you raised earlier, it is perfectly fine for
an XML serialisation to use numeric character references and entity
references like this (i.e., it’s well formed XML).

In the example below, it’s true that the apostrophes need not be
replaced with entities inside double-quoted attributes.  I’m not sure if
the serialisation code sometimes uses double-quoted attributes and
sometimes single-quoted attributes; if it does, then it may use &apos;
unconditionally just because it is simpler to do so.  But if it’s usign
double-quoted attributes all the time, then I agree it’s better if it
didn’t use &apos;.

Can you submit a small, standalone program that demonstrates the
problem?

> And why is batik omitting the last character if it has to do something  
> with entities? For example:
>
> * If I try to set an attribute to &#xFC; (I did that before I knew that  
> all entities are replaced every time), As result I get: &amp;#xFC. The &  
> is replaced with it's entity, this is ok, but the semicolon disappeared.
>
> * If I have single quotes in attribute values (Adobe Illustrator seems  
> to do this writing the font names), those single quotes are replaced  
> with their entity &apos; and the last character of the string within the  
>  single quotes disappears:
>
> 	Original: font-family="'ArialNarrow-Bold'"
> 	Batik written: font-family="&apos;ArialNarrow-Bol&apos;"
>
> I am using Batik-1.8pre. Is this a known bug?

I don’t think that’s a known bug, no, but it does look like a bug.  As
above, can you provide a test case?

Thanks,

Cameron

-- 
Cameron McCormack ≝ http://mcc.id.au/

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org