Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #11884 > unrolled thread

PHP functions to convert markup efficiently

Back to article view | Back to comp.lang.php

Contents

  PHP functions to convert markup efficiently "James Harris" <james.harris.1@gmail.com> - 2013-11-21 18:30 +0000
    Re: PHP functions to convert markup efficiently The Natural Philosopher <tnp@invalid.invalid> - 2013-11-21 18:39 +0000
      Re: PHP functions to convert markup efficiently "James Harris" <james.harris.1@gmail.com> - 2013-11-21 18:57 +0000
        Re: PHP functions to convert markup efficiently Christoph Michael Becker <cmbecker69@arcor.de> - 2013-11-21 20:10 +0100
          Re: PHP functions to convert markup efficiently "James Harris" <james.harris.1@gmail.com> - 2013-11-21 19:29 +0000
            Re: PHP functions to convert markup efficiently Christoph Michael Becker <cmbecker69@arcor.de> - 2013-11-21 21:18 +0100
    Re: PHP functions to convert markup efficiently Salvatore <sal@yojimbo.hack.invalid> - 2013-11-21 19:03 +0000
    Re: PHP functions to convert markup efficiently Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-11-21 21:27 +0100
    Re: PHP functions to convert markup efficiently Arno Welzel <usenet@arnowelzel.de> - 2013-11-22 11:33 +0100
      Re: PHP functions to convert markup efficiently "James Harris" <james.harris.1@gmail.com> - 2013-11-22 12:48 +0000
        Re: PHP functions to convert markup efficiently Jerry Stuckle <jstucklex@attglobal.net> - 2013-11-22 08:53 -0500
          Re: PHP functions to convert markup efficiently "James Harris" <james.harris.1@gmail.com> - 2013-11-23 06:21 +0000
            Re: PHP functions to convert markup efficiently Jerry Stuckle <jstucklex@attglobal.net> - 2013-11-23 06:59 -0500
            Re: PHP functions to convert markup efficiently Christoph Michael Becker <cmbecker69@arcor.de> - 2013-11-23 13:12 +0100
        Re: PHP functions to convert markup efficiently Arno Welzel <usenet@arnowelzel.de> - 2013-11-22 16:42 +0100
          Re: PHP functions to convert markup efficiently "James Harris" <james.harris.1@gmail.com> - 2013-11-23 16:38 +0000
            Re: PHP functions to convert markup efficiently Richard Yates <richard@yatesguitar.com> - 2013-11-23 13:24 -0800
              Re: PHP functions to convert markup efficiently "James Harris" <james.harris.1@gmail.com> - 2013-11-23 22:07 +0000
            Re: PHP functions to convert markup efficiently Arno Welzel <usenet@arnowelzel.de> - 2013-11-24 17:09 +0100
              Re: PHP functions to convert markup efficiently "James Harris" <james.harris.1@gmail.com> - 2013-11-24 18:11 +0000
                Re: PHP functions to convert markup efficiently Arno Welzel <usenet@arnowelzel.de> - 2013-11-24 23:18 +0100
                  Re: PHP functions to convert markup efficiently "James Harris" <james.harris.1@gmail.com> - 2013-11-24 23:44 +0000
                    Re: PHP functions to convert markup efficiently Arno Welzel <usenet@arnowelzel.de> - 2013-11-25 08:11 +0100
    Re: PHP functions to convert markup efficiently "James Harris" <james.harris.1@gmail.com> - 2013-11-23 19:21 +0000

Page 2 of 2 — ← Prev page 1 [2]

#11964

James Harris, 2013-11-24 19:11:

> "Arno Welzel" <usenet@arnowelzel.de> wrote in message 
> news:529224C1.4060400@arnowelzel.de...
>> James Harris, 2013-11-23 17:38:
>>
>>> "Arno Welzel" <usenet@arnowelzel.de> wrote in message
>> [...]
>>>> Besides Markdown and Smarty you can also try DokuWiki - it's markup can
>>>> be extended using syntax plugins (and you can create your own plugins as
>>>> well to handle block level or inline elements etc.).
>>>
>>> I took a look at DokuWiki (having previously looked at the others). It's
>>> good but does things I don't want. At first glance I couldn't see a way 
>>> to
>>
>> What exactly?
> 
> Would exactly would I want to prevent it doing? Unfortunately, most of it! 
> Things like:
> * automatic conversion of URLs which are not marked up

This can at least be avoided "manually" by embedding an URL within %% -
e.h. %%http://something.example%% would not be converted to a link.

> * automatic lowering of the case of page names

This can be changed in the code - according to
<https://forum.dokuwiki.org/thread/5417>:

In function cleanID(), located in inc/pageutils.php just comment out the
line with

$id = utf8_strtolower($id);

> * interwiki links

If you don't need them, remove all of them in conf/interwiki.conf.

> * windows shares links
> * ALL of its smileys

This is also configuration option and can be turned off.

> * its Usenet-style quoting

I'm not sure where to turn this off - but it should be possible.

> * most table cell merging

You don't like the way it works? Or don't you like the possibility to
merged table cells at all?

> * embeddable HTML and PHP

Which is also a configuration option and turned off by default anyway.



-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#11965

"Arno Welzel" <usenet@arnowelzel.de> wrote in message 
news:52927B39.3020407@arnowelzel.de...

...

>>>>> Besides Markdown and Smarty you can also try DokuWiki - it's markup 
>>>>> can

...

>> Would exactly would I want to prevent it doing? Unfortunately, most of 
>> it!
>> Things like:

...

>> * most table cell merging
>
> You don't like the way it works? Or don't you like the possibility to
> merged table cells at all?

There may be a need to make merging impossible. I have in mind making tables 
sortable (by means of client-side JavaScript). That would not work with 
merged cells.

Thank you for going to the trouble of making suggestions (snipped) for the 
points I raised.

James

[toc] | [prev] | [next] | [standalone]

#11976

James Harris, 2013-11-25 00:44:

> "Arno Welzel" <usenet@arnowelzel.de> wrote in message 
> news:52927B39.3020407@arnowelzel.de...
> 
> ...
> 
>>>>>> Besides Markdown and Smarty you can also try DokuWiki - it's markup 
>>>>>> can
> 
> ...
> 
>>> Would exactly would I want to prevent it doing? Unfortunately, most of 
>>> it!
>>> Things like:
> 
> ...
> 
>>> * most table cell merging
>>
>> You don't like the way it works? Or don't you like the possibility to
>> merged table cells at all?
> 
> There may be a need to make merging impossible. I have in mind making tables 
> sortable (by means of client-side JavaScript). That would not work with 
> merged cells.

JFTR: This plugin allows sortable tables in DokuWiki using JavaScript:

<https://www.dokuwiki.org/plugin:sortablejs>

More detailed explanation with live samples:

<http://docs.oseems.com/general/web/dokuwiki/sort-table>


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#11946

"James Harris" <james.harris.1@gmail.com> wrote in message 
news:l6ljfj$fue$1@dont-email.me...

>I am looking for a way to mark up text in a way that PHP would be able to 
>efficiently and quickly convert to HTML.

In case anyone is interested, here is what I have come up with so far.

The markup is designed to be fast to parse rather than to be beautiful. 
However, it doesn't look too bad, IMO. I'll explain the markup first and 
then the PHP which carries out the conversion.

This is very much experimental at this stage. I may well have to change any 
of this including the tag formats. But it is working code as it stands.

There are simple tags which have a one-to-one translation. Here are some 
examples. The markup is on the left and what it translates to on the right.

  @(hr)  -->  <hr>
  @(b)  -->  <b>
  @(/b)  --> </b>
  @(nl)  -->  <br>
  @(at)  -->  @

For example, "Please @(b)STOP@(/b) here" will print STOP in bold and the 
rest non-bold.

There are markup tags with simple parameters such as these.

  @(h,2)  -->  <h2>
  @(/h,2)  -->  </h2>

And there are tags which are more inclusive such as these.

  @(sect,2,Section X)  -->  <h2>Section X</h2>
  @(link,Local Page)  -->  <a href="Local Page">Local Page</a>
  @(link,http://xe.com,XE)  -->  <a href="http://xe.com">XE</a>

As you can see, a markup tag is identified by an @ sign followed by an 
opening delimiter. The opening delimiter is "(" in all the above cases but 
could be a different character. Each opening delimiter character has a 
corresponding closing delimiter. For most punctuation characters the closing 
delimiter is the same as the opening delimiter but for pairable bracket 
characters the logical closing bracket is used. Therefore the following all 
mean the same.

  @(i)
  @[i]
  @|i|
  @*i*

The point is that the person writing the code can and must choose a closing 
delimiter that does not appear in the text between the delimiters. This is 
to help recognition speed; the complete tag can be isolated without needing 
to consider context such as quoted strings.

I haven't performed timing comparisons but I took Christoph's advice for 
speed and chose to use PHPs inbuilt functions which are likely written in C. 
I try to avoid calling them repeatedly so as to avoid call overhead. As a 
result, the markup parsing works as follows. Feel free to criticise.

First, the page of marked-up text has htmlspecialchars() applied and then is 
split on @ symbols using a single call to PHP's explode(). This creates an 
array of strings which, for the sake of something to name them, I call 
Sections. The PHP code is, in essence, as follows.

  $contents = file_get_contents($target_page);
  $contents = htmlspecialchars($contents, ENT_NOQUOTES);
  $sects = explode("@", $contents);
  $contents = ""; //Original text no longer needed

The first section, $sects[0], is what preceded the first @ sign. It is not 
marked up so it is written verbatim and then split off using the following 
code.

  echo $sects[0];
  $sects = array_slice($sects, 1);

Second, for each remaining section the initial character (which followed an 
@ sign) is taken as an opening delimiter and a matching closing delimiter is 
chosen. Then explode(,,2) is called to split the section into just two 
parts: before and after the closing delimiter. The most important part of 
that is

  $sectparts = explode($delimiter, substr($sect, 1), 2);

This converts each section into two parts: a tag and some text.

Third, so that tag parameters can include whatever is necessary, especially 
for where the include commas in quoted strings, I use the CSV module as 
follows.

  $tagparts = str_getcsv($sectparts[0]);

That divides the complete tag into manageable parts. All that's left is to 
deal with each part as in

  switch ($tagparts[0]) {
  case "at":           echo "@"; break;
  case "b":            echo "<b>"; break;
  etc.

Finally, once the tag has been written the following non-tag text is written 
with

  echo $sectparts[1];

That's it so far. I may have missed something fundamental but so far it 
seems to work well. It is simple and flexible and the code is very short. No 
need for a complex package. There are a few functions I would rather have 
not had to use but PHP seems to require them. In any case, the code avoids 
things which might slow it down such as large packages, char-by-char 
processing (except, presumably, in the CSV module) and regular expressions. 
So it should be fast as it stands.

James

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.php

csiph-web