Custom typography.quotes.primary strings

[fvsch]

Not sure that's something you have control over, if the options come from the libraries used.

I was thinking that for typography.quotes.primary and typography.quotes.secundary it would be nice to be able to provide custom strings, like:

c::set('typography.quotes.primary', '« foo »');

The foo string or another marker would act as a way to detect a custom setting and split the opening/closing parts.

[fvsch]

Though my need for that may be managed by typography.space.nobreak.narrow. (Probably not fully because French calls for narrow no-break spaces most of the time, but a full no-break space before :.)

[fabianmichael]

There is the setting typography.punctuation.spacing.french, which inserts the space right before the colon. And there is also the the quote style doubleGuillemetsFrench available. But it uses regular no-break space. If the narrow space is more suitable for any text, written in french, I can override that (is it?).

In the source, it looks like this:

'doubleGuillemetsFrench'   => array( 'open'  => $this->chr['guillemetOpen'].$this->chr['noBreakSpace'],
                                                 'close' => $this->chr['noBreakSpace'].$this->chr['guillemetClose'] ),

Although my plugin is based on wp-Typography, it is currently not possible to use the library without overriding some methods and changing some small portions of the original source, because some methods are private, but I need to call them on initialization. If we need to fix another thing, this won’t be a problem. Maybe I will try to setup a PR to the maintainer in the near future, so I can possibly use the vanilla files someday.

Maybe, it could be helpful to setup defaults for every language, but I could not handle this alone. I only know (most) typographic convention for German and for English.

[mundschenk-at]

Which methods would you need? I'd gladly make them protected to allow you to subclass things. I wouldn't want internal helper methods to be public, though.

[mundschenk-at]

Regarding the use of narrow no-break space: I've experimented with that, but browser/font support is quite bad. Often, it is rendered wider than a regular no-break space.

[fabianmichael]

@mundschenk-at Thanks for joining the discussion and – of course – thanks for maintining this awesome library! :-)

Regarding the narrow no-break space: I added a note to my documentation, warning users that this glyph is missing in most fonts. Nevertheless, enabling this option should also update the regex for the doubleGuillemetsFrench quote-style.

Another question: Is this only affecting IE6 or are there other reasing for not using the real hyphen character?

# Line 232
$this->chr['hyphen']                  = '-';        // should be uchr(8208), but IE6 chokes;

Regarding the changes, I made:

• I removed the require_once dirname( __DIR__ ) . '/vendor/Masterminds/HTML5.php'; statement, because I use a classmap for autoloading, following Kirby’s scheme of how to handle this. I changed the file structure according to my needs, but I can change that back, because the HTML5 classes are only used by PHP_Typography and do not need to be autoloadable, when PHP_Typography is not loaded.
• I want to be able to make the classes of CSS hooks user-definable. To do this, I extend the PHP_Typography class and override methods like style_caps. In th overriding method, I just copy the source code of the initial function and use classes from an option instead of the default ones. This should be easy to fix, by using a variable on the PHP_Typography class, containing all class names. But currently, I need to access the PHP_Typography->regex[] array for achieving this. I would prefer not to copy/override such large portions just for just adding CSS classes, because this makes updating of my plugin much harder.
• The regex for hanging punctuation is only defined when initialize_patterns() is called, which is a private method. I was not able to make it work properly, when changing the quote style. I think, the issue is that update_smart_quotes_brackets() (called by set_smart_quotes_primary()) does not update $this->regex['styleHangingPunctuationDouble'], $this->components['doubleHangingPunctuation'] etc. So I just did a quick fix by changing this method to protected and called it dirrectly. Would be nice, If you could check this.

[mundschenk-at]

Hyphen: That's a legacy comment, but I have not done any research about the availability of proper hyphen glyphs in fonts (& browser support). The next release of wp-Typography will drop IE6 support, so I may revisit that.

CSS classes: Yes, I can add some variables (probably: elements in the PHP_Typography->component[] array with some accessor methods) to allow the CSS output to be customized.

Hanging punctuation: I'll have a look at it. The push/pull classes were great in theory but didn't work as well in practice, so I haven't done a lot with that feature since implementing initial support. Making the helper methods protected should not be a problem either.

[fabianmichael]

@mundschenk-at Thank you very much for your support. When you implement CSS classes as configurationable options, I would also like to see the possibility of adding a class to the <sup> and <sub> tags of smart fractions (could be optional), because in some fonts like Source Sans Pro, the spacing between numbers and the fraction slash is very small.

What problems did you encounter with hanging punctuation?

[mundschenk-at]

I couldn't get hanging punctuation to work properly with justified paragraphs. Also the markup is not great from a semantical code point of view.

[fabianmichael]

Okay, yeah the markup if pretty ugly … I think the more important feature are initial quotes. But actually, I also like hanging punctuation for left-aligned text. I will definitely give it a try on the next update of my own website! :-)

[mundschenk-at]

@fabianmichael, why would you want to update the hanging punctuation pattern when setting different quote characters? The Regex should already contain all the small glyphs that should be hung. Guillemets are IMHO too much like regular characters (size, line position) to be hung and all the other possible quote characters (except the Asian ones, I've got no idea regarding the conventions for their use) are already there.

[mundschenk-at]

@fabianmichael I've just added a branch that makes the CSS classes configurable via PHP_Typography::css_classes.

[fabianmichael]

@mundschenk-at I finally had time to look into literature. Unfortunately, my favorite book on this topic (Detailtypografie did not contain any information on this. Other books said, that this is more suitable for short amounts of text with only a few lines.

InDesign does hanging punctuation as follows:

So my guess here is, that it is better for most cases not to outdent guillemets. I will close this issue soon.

Thanks for adding the branch. Should I always take files from this branch from now on or should I just wait for wp-Typograpgy 3.3 to be released and use the master branch after that?

BTW, are you using Kirby, too? ;-)

[mundschenk-at]

@fabianmichael Just use the master branch. The Kirby branch was only for development and will disappear in the near future.

To be honest, I had never even heard of Kirby before stumbling onto your plugin, so no, at the moment I'm strictly a WordPress person ;-)

[fabianmichael]

This issue ended up with handling more topic than the title suggestens. But nevertheless, everything should be clear by now.

The initial issue (mentioned in the title) will not fix, because it is related to PHP-Typography.