Symphony.

A new extension, “Typography Text Formatters” is now available for download. Comments and feedback can be left here but if you discover any issues, please post it on the issue tracker.

Typography Text Formatters updated to version 1.0.1 on 30th of March 2010

Nice work!

It would be rather cool to be able to add settings for phpTypography without hacking the formatter files! (No need to save to the database - maybe an XML file placed in /manifest would be cool.)

Yeah, I agree. I’ll have a look at some of the other formatters and add some settings - I’m sure I saw a text formatter recently with settings…

Rowan’s HTML Formatter possibly?

As of today we’re abandoning the Textile text formatter in favour of Markdown, it’s simply proven too slow and buggy to be worth our time.

As an example, I was using the XML Importer to import about 22 entries, each entry had about 30 fields with around 10 characters of text, each field was using Textile.

So to pass about 300 characters through Textile (but not all at one time) it took several minutes. When I switched the fields to use the HTML Formatter above, it took 8 seconds.

@brendo - yep, that’s the one. I’ll draw something up as soon as I can - but looking at HTML Formatter, it has come a long, long way! It made me consider switching back to HTML for my blog posts again :)

As of today we’re abandoning the Textile text formatter in favour of Markdown, it’s simply proven too slow and buggy to be worth our time.

Sounds good to me! I only ever use Markdown Extra on my personal works now anyway.

Less to look after ;)

The plan is at some point to allow other text formatters to be plugged into the HTML formatter, so you’d have all the same settings, but a different processing engine to create the initial HTML.

Maybe it’s more worthwhile for me to put my energies into helping to do that? The typography extension is nice, but it’s going to take a fair bit of effort to make it as functional as your HTML formatter.

Ponderances. But first, a weekend. A very long weekend!

I’d appreciate the help for sure. Basically, the ‘HTML’ Formatter extension will have a couple of delegates to allow text formatting engine extensions to interact:

TextFormatterEngineAnnounce

Allows a text formatter engine to add itself to the list of available engines. It’s context param would contain an array which you can append a unique handle, title and description to:

public function delegateTextFormatterEngineAnnounce($context) {
    $context['engines'][] = array(
        'handle'      => 'markdown',
        'title'       => __('Markdown'),
        'description' => __('Format text using Markdown.')
    );
}

TextFormatterEngineApply

Apply the text formatter engine to a string:

public function delegateTextFormatterEngineApply($context) {
    $context['text'] = General::sanitize($context['text']);
}

Of course, this is all of the top of my head, but I’m pretty sure that this is all that you’d need to get Markdown plugged into the HTML Formatter. All that’s left to do is everything.

Hi Tony,

I was using your Typography text formatter and had the need for more finegrained typographic settings depending on the site language. So I started rearranging your extension to offer a settings pane in the preferences to let the user choose which local typographic settings he needs.

http://github.com/nilshoerrmann/typography

My fork contains a lot of changes - I rewrote a lot of the code. There are now separate typography classes for English, standard German and German with guillemets and it’s possible to add other languages easily.

I hope these changes are fine for you and I would be nice if they could be pulled into the main repository.

Nils

PS: I renamed my repository from “symphony-typography” to “typography” because you’ll not be able to use the extension when you copy it to your extension folder with the former name.

You are prolific, Nils - and you beat me to it! I’ll take a look at the changes later today and hopefully merge them back into the main repository. I’ll post back here when it’s done - Thanks!

The PHP Typography class seems to have some problems to distinguish apostrophes and closing single quotes. This is especially visible in German as we use different characters for apostrophes and closing single quotes. I added a fix for this issue to my fork.

There seems to be compatability issues with WMD editor.

This took a bit of time for me to figure out, but if you’d like to get this to work with the WMD Editor you will have to modify wmdeditor/assets/jquery.wmd.function.js and add the selectors: textarea.typographywithmarkdown, textarea.typographywithmarkdownextra to the jQuery(“”).wmd() line (line 2).

However, a better fix would be if this extension adds a markdown class to the textarea in the admin interface. Didn’t put it under “issues” as it is not really a bug, but nice if it were done.

Thanks for the extension by the way!

However, a better fix would be if this extension adds a markdown class to the textarea in the admin interface. Didn’t put it under “issues” as it is not really a bug, but nice if it were done.

This is not a specific problem of this formatter as Symphony automatically uses the formatter name as class name. As this extension provides PHP Typography as its main formatter and uses either Markdown or Textile to generate the needed markup the names typographywithmarkdown and typographywithmarkdownextra seem to be correct the way they are.

So I think this issue should be solved inside the WDM text formatter, e. g. using the following code:

jQuery().ready(function() {
    jQuery("textarea[class*='markdown']").wmd({
        "preview": false,
        "helpLink": "http://daringfireball.net/projects/markdown/",
        "helpHoverTitle": "Markdown Help",
    });
});

I was just looking at using a ‘Textile’ Text Formatter when I found this ‘Typography Text Formatters’ extension.

Reading the thread I’m confused: is Textile no longer supported? Is this extension deprecated?

I’ve chosen to disable Textile support in my Typography extension. I don’t know if that’s being done in Symphony’s Core, but I’d imagine given Rowan’s comment that it’s likely.

Cool. I understand the reasons for disabling Textile but the current status was a little unclear.

This is actually a little issue I encounter more often: it seems the current status of an extension is documented all over the place. Not everyone uses GitHub, so commit logs alone are not enough. It’s probably best to edit the extension Description on the Extension download page. Not everybody seems to do this consistently (*cough* :) ).

This requires users to wade through forum discussions to find the current status of/updates to an extension.

Why don’t extension authors update the Extension page itself and add a Changelog there, instead of in the discussions?

(Forgive me if I overlook some Symphony Extensions Policy here…)

It’s worth starting a new thread for this — we should discuss this in isolation to this extension to establish some best practices.

@Nickdunn Done