kingjeffrey

pik256,

I am still having difficulty recreating your error.

I have tried pasting the text provided, and inserting no-break spaces in the form of & nbsp;, & #160;, & #xA0;, and & #x00A0; (with the space trailing the & removed). I did all the editing in WordPress’ HTML editor in IE.

I then tried to work within Visual Editor, manually typing a no-break space with ctl-shift-space.

In all instances, everything displayed as expected.

hexdreamer,

Thanks for pointing this out. Your comment revealed a minor bug that slipped in via the last code update. Version 1.17 should be available within the next 15 minutes with the fix.

pik256,

Unfortunately, I am unable to reproduce the problem. Could you provide me some sample text; something I can copy and paste into the WordPress editor? Thanks.

pik256,

Thanks for raising this issue. Your solution does not just resolve the problem, it turns off dewidowing entirely. That can also be done in the admin settings (without hacking the code).

I will see if I can reproduce the bug and fix it in an update.

@ryanr14

I highly doubt there is a jQuery conflict. jQuery operates client-side (on the browser once a page is served). wp-Typography operates completely on the server _before_ the page is served.

Your problem seems related to the theme authors using improper WordPress functions to place content inside HTML tags. Only WordPress functions that do not leverage filter hooks should be used in this instance. See this FAQ for more information.

@pik256

Thank you for the suggestion. UTF-8 encoding is a disclosed requirement of the plugin.

While skipping the htmlspecialchars() instruction for non UTF-8 encodings will avoid the warning, it will not fix the problem. The execution of this function is needed for the proper operation of the plugin. By not conditionally bypassing the function, at least a warning is generated to give the administrator notice there is a failed dependency.

The fix was included in version 1.14

Thank you for bringing this to my attention. I will release the fix shortly.

The curled quotemarks above are the same Unicode characters used in wp-Typography’s smart quote replacement. If your quotemarks appear differently, the issue is more likely the font used on your website. Every font defines what the unicode characters look like. Just as the letter “a” will appear differently with Georgia or Verdana fonts, so will quotemark characters.

If you like the font used on these forums, the CSS declaration is:

font-family: "Lucida Grande",Verdana,"Bitstream Vera Sans",Arial,sans-serif;

You can update your themes CSS file with these font families.

@prometh

Typographically speaking, there are very specific characters for quotemarks. This plugin (optionally) forces these characters. I am unaware of any Unicode characters that can validly be used in place of these.

If you are not seeing these quotemarks when you use the plugin, you may have not turned on the “Intelligent Character Replacement” options in the administrative menu.

Gene,

As far as I am aware, WordPress does not provide a means for plugins to know what page is being processed. As such, there is no way to directly block a URL from processing.

You could edit that page and wrap the entire content area in a <div class="noTypo">, and verify the class “noTypo” is included as an excluded class in the wp-Typography options page.

Best of luck.

With the caching plugin, the load time will be the same for the first page load. After that, no processing will occur until the cache expires. Note that if you view the source, often themes include a timer output at the bottom. That output is cached as well. So if it takes 1 sec. for the first load, it will continue to say “1 sec.” as long as the cached version is served (even though the cached version is loading much quicker).

To edit the theme, log in as an administrator and go to: Appearance > Editor. You will typically want to edit the following files (if they exist):

• archive.php
• index.php
• page.php
• search.php
• single.php

In each file, search for the code that looks something like this:

<h2><a href="<?php the_permalink() ?>" rel="bookmark" title="Permanent Link to <?php the_title(); ?>"><?php the_title(); ?></a></h2>

There may be some variations. For instance, the h2 tags may be h1 or h3… It should be changed to:

<h2><a href="<?php the_permalink() ?>" rel="bookmark" title="Permanent Link to <?php the_title_attribute(); ?>"><?php the_title(); ?></a></h2>

Save the files, and you should be good to go.

Gene,

Both of these issues are addressed in the wp-Typography FAQs, but I’ll summarize here:

1. There is a tremendous amount of processing that is done for each page load. Load times are slower. My experience, for a normal blog post, load times remain below 1 second. For a complicated front page, it can near 2 seconds. I highly recommend you use WP Super Cache with wp-Typography.
2. You are seeing the extra characters at the beginning of each title because your theme uses the wrong function to provide the title attribute to the headings’ links. Your theme uses the_title() which provides the post title after any plugin filtering. This will cause complications whenever injected in an HTML attribute. Your theme should use the_title_attribute() which provides the post title without plugin processing. If you are uncomfortable editing your themes, you can enter h1 and h2 into the excluded HTML elements field in the wp-Typography settings to turn off all typographic processing of your headings.

wp-Typogrify (mentioned above) has now officially been replaced by wp-Typography, which plays much nicer with shortcodes. The new plugin also replaces wp_texturize with an improved and expanded take on SmartyPants.