headers
Christoph Thielecke | 7 Feb 09:32
Picon

Re: Petal problem

Am Montag, 7. Februar 2005 01:25 schrieb Bruno Postle:
> On Sat 05-Feb-2005 at 22:48 +0100, Crissi wrote:
> > But it fails on a html file which is correct xml and i could not
> > find a mistake for use of Petal. It fails only on that file other
> > files will be processed successfully.
> >
> > I found the reason, the translated text is:
> > -- snip --
> > (for example: ${1})
> > -- snap --
>
> I'm not sure I know what you mean, could you provide a longer piece
> of XML, or attach a file that causes Petal to fail?
I made a howto which describes howto use petal for translating webpages. In 
the XHTML file I wrote:

-- snip --
Attention: If text which should be translated contains other tags you will get 
a reference instead of the tag (for example: ${1}).
-- snap --

If the "${1}" is in the text the parser fails.

Could you proove it?

greetings

Christoph
--

-- 
Linux User Group Wernigerode
(Continue reading)

Permalink | Reply |
headers
Bruno Postle | 11 Mar 18:39
X-Face

Re: Petal problem

On Mon 07-Feb-2005 at 09:32 +0100, Christoph Thielecke wrote:
>
> If the "${1}" is in the text the parser fails.

Right, I've confirmed this.

Any Petal template with "${1}" in it fails because 
Petal::Hash::String thinks it looks like a variable but 
Petal::Hash::Var disagrees.

It is valid XML, but anything with '$' in it is going to be 
problematic because Petal uses it for variable substitution.

The following items all survive the Petal Parser untouched:

  <a>$</a>
  <b>$$</b>
  <c>$_</c>
  <f>$@</f>
  <g>$1</g>

..these are interpreted to nothing if they are undefined:

  <d>$foo</d>
  <e>${foo}</e>

..and these fail inelegantly:

  <h>${1}</h>
  <i>${1 bar}</i>
(Continue reading)

Permalink | Reply |
headers
William McKee | 14 Mar 16:22
Favicon

Re: Petal problem

On Fri, Mar 11, 2005 at 05:39:10PM +0000, Bruno Postle wrote:
> It is valid XML, but anything with '$' in it is going to be 
> problematic because Petal uses it for variable substitution.

But according to the POD, it's a deprecated syntax[1] so why even
support it?

William

[1] http://search.cpan.org/~bpostle/Petal-2.15/lib/Petal/Deprecated.pm#INLINE_VARIABLES_SYNTAX

--

-- 
Knowmad Services Inc.
http://www.knowmad.com
Permalink | Reply |
headers
Bruno Postle | 14 Mar 17:41

Re: Petal problem

William McKee wrote:
> On Fri, Mar 11, 2005 at 05:39:10PM +0000, Bruno Postle wrote:
> 
>>It is valid XML, but anything with '$' in it is going to be 
>>problematic because Petal uses it for variable substitution.
> 
> But according to the POD, it's a deprecated syntax[1] so why even
> support it?

Because removing it would break existing templates.

It is deprecated because it is ugly and breaks the WYSIWYG test of 
hiding scary programming stuff from web-designers, but it is still 
useful functionality.

A quick check shows there are 63 instances in MKDoc-1.6 and 34 in 
MKDoc-1.8 templates - Though I suppose we ought to try and get rid 
of them.

--

-- 
Bruno
Permalink | Reply |
headers
wsmith | 15 Mar 19:58

Petal and &nbsp;

This has probably been beaten to death, and if someone could point to
which archives to look through, I would appreciate it. I was just
wondering if anyone has any input in the fact that petal changes &nbsp;
to &amp;nbsp;, but does *not* modify &#160; (the unicode equivilant). Is
this a bug or how petal is supposed to work?

-Warren
Permalink | Reply |
headers
William McKee | 18 Mar 15:12
Favicon

Re: Petal and &nbsp;

On Tue, Mar 15, 2005 at 12:58:29PM -0600, wsmith wrote:
> This has probably been beaten to death, and if someone could point to
> which archives to look through, I would appreciate it. I was just
> wondering if anyone has any input in the fact that petal changes &nbsp;
> to &amp;nbsp;, but does *not* modify &#160; (the unicode equivilant). Is
> this a bug or how petal is supposed to work?

Hi Warren,

In my case Bruno's advice was not a solution. I was always using XHTML
as the INPUT. I've attached my running commentary about this issue which
has been plaguing me ever since the upgrade to 2.0 where Jean-Michel
began using Unicode when importing the text if your version of Perl was
5.7+. The comments are a bit rambling and I'm preferring the solution of
tweaking the header vs. forcing the output via Encode::encode these
days but you'll find some helpful info (and hopefully not too much
misinformation).

The crux of my problem was a lack of understanding about Unicode.  Take
the time to learn how that works and this problem won't seem so
mysterious. You'll need to understand it one day, anyhow.

HTH,
William

Petal and  characters

<p>Petal is printing  characters into my HTML output again. This character is
a capital A circumflex (Acirc) and is Hex C2 (\x{c2}), Dec 194, Oct 302. If
viewed in UTF8 encoding, this is a space. Somehow this character is getting
(Continue reading)

Permalink | Reply |
headers
Bruno Postle | 15 Mar 21:48
X-Face

Re: Petal and &nbsp;

On Tue 15-Mar-2005 at 12:58 -0600, wsmith wrote:

> I was just wondering if anyone has any input in the fact that 
> petal changes &nbsp; to &amp;nbsp;, but does *not* modify &#160; 
> (the unicode equivilant). Is this a bug or how petal is supposed 
> to work?

Yes, this is because Petal is treating your template as XML.  If you 
create a template like this:

  <a>&nbsp;&#160;</a>

..and process it like this:

  $Petal::INPUT = 'XHTML';
  my $a = new Petal ('nbsp.xml');
  print $a->process;

As expected, you get two identical non-breaking-space characters:

  <p>  </p>

If you process it like this (XML is the Petal default):

  $Petal::INPUT = 'XML';
  my $a = new Petal ('nbsp.xml');
  print $a->process;

..suprisingly, you see this output:
(Continue reading)

Permalink | Reply |

Gmane