• View
• Edit
• History
• Attach
• Print

00357

Description: The markup [-...-] does not work if the german i18n is enabled. The HTML always shows 'font-size:100%' for the text in question.

I have trackt this down to an issue of the numeric locales. Obviously the function to calculate the font size (stdmarkup.php:119) no longer can handle the '.' as decimal separator and thus only works with integer values. This could also be problem for other markups, I did not check this.

This issue can be resolved by changing the numeric locale back to 'en_US' in pmwiki.php. I changed pmwiki.php:474 from:

    if ($xl['Locale']) setlocale(LC_ALL,$xl['Locale']);

To:

    if ($xl['Locale']) {
      setlocale(LC_ALL,$xl['Locale']);
      setlocale(LC_NUMERIC,'en_US');
    }

This is probably not the real intention of a complete i18n, so there might be other resultions. But at least it works for now.

Christian

Very odd. It seems to work on pmwiki.org, even with the german i18n enabled. See Test.TestDe. The stdmarkup.php file explicitly recognizes the problem of decimal points in other locales by always rounding the output to an integer value. So there must be something else going on here. It's equally bizarre that you were able to "fix" it by using setlocale above.

Here's the code:

    ## big, small
    Markup('[+','inline',
      '/\\[(([-+])+)(.*?)\\1\\]/e',
      "'<span style=\'font-size:'.(round(pow(1.2,$2strlen('$1'))*100,0)).'%\'>'.
        PSS('$3</span>')");

This says we're converting any text surrounded by either [+...+] or [-...-] to have a <span style='font-size:...'> tag around it. The value of font-size is computed as a percentage value with:

    round(pow(1.2,$2strlen('$1'))*100,0)

Here, $1 is the sequence of +'s or -'s. $2 is a single + or -. Thus, for [-small text-] we get

    round(pow(1.2,-strlen('-'))*100,0)

which becomes

    round(pow(1.2,     -1     )*100,0)

which no matter how I look at it appears to me to be a straightforward numeric calculation -- i.e., no conversions between strings and numbers that would involve decimal points or any sort of locale information. The result of this would be

    round(0.833333333333 * 100,0)

or

    round(83.33333333333,0)

resulting in a value of 83 which should then be converted to a string. In fact, the only way we can end up with 100 is if the result of pow(1.2, -1) is somehow coming out as 1. Can it be that PHP is incorrectly treating 1.2 as "1" simply because it's a string argument to preg_replace?

Totally bizarre. I suspect a PHP bug here, but I need to see it failing somewhere before I can easily fix it.

In the meantime, could you try changing stdmarkup.php:119 to use "6/5" instead of "1.2" and see if that resolves the problem?

--Pm

First of all, sorry for my late response.

I had analyzed the calculations of the [-...-] markup myself. It's really straight forward and I would have done it in a similary way.

I assume the PHP problem comes from the the PHP command being a string which is executed later. But it's strange that the test at pmwiki.org works. Which version of PHP is pmwiki.org running? The PHP-version of my server is already listed at the top of this site.

Nevertheless I have tried your fix with "6/5" instead of "1.2" and it works fine! I have reverted my changes in pmwiki.php and replaced the "1.2" with "6/5" in stdmarkup.php, and now [-...-], [--...--], [+...+], [++...++] look like they should :-)

Thanks for the help!

--Christian

I'm going to guess that it's indeed a bug in PHP 4.1.2. pmwiki.org is currently using 4.3.2. At any rate, I've changed the code for beta29 to use 6/5 instead of 1.2, since that seems to work.

--Pm