M2mobi / Marky-Mark

Markdown parser for iOS
MIT License
301 stars 66 forks source link

No support for Bold Italic #75

Open mhoeller-clue opened 5 years ago

mhoeller-clue commented 5 years ago

Currently the library does not support inline bold italic text, denoted by ***text***. I've seen a BoldItalicMarkDownItem class, but full support does not seem to have been added yet.

jvanzummeren commented 5 years ago

Hi mhoeller-clue,

I'm not sure what you mean with 'full support', but your example seems to be working and is also part of the example project. Attached a screenshot of the current Example project.

Kind regards,

Jim

screenshot 2018-11-22 at 21 41 25
mhoeller-clue commented 5 years ago

I tried the example and indeed it works there. The problem in my case is apparently the custom font we use in our app... It has each of its variants (e.g. bold italic) in a separate file 🤦‍♂️. So what I'm really missing here is a way to customize the bold italic styling like I can do with just italic:

textView.styling.italicStyling.baseFont = ...

I tried to work around this by using *text* and setting our bold italic font as the italicStyling.baseFont, but markymark takes away the bold trait while processing the markdown in ItemStyling.makeItalic().

So the suggested solution is to provide boldItalicStyling in DefaultStyling. This is also what I meant with "full support".

Basca commented 5 years ago

Hey mhoeller-clue,

I've looked a bit further into the issue, and understand your issue when you have a custom font in a separate file for bold italic as combination.

Currently the solution as Jim showed is using UIFontDescriptor.SymbolicTraits, looking for a font with the traits:

func makeItalicBold() -> UIFont? {
        if let descriptor = fontDescriptor.withSymbolicTraits([.traitItalic, .traitBold]) {
            return UIFont(descriptor: descriptor, size: pointSize)
        }

        return nil
    }

But that won't work in your case with your custom font where each trait has it's own file.

To be able to support your use-case we will have to look a bit further into the core. This is however an improvement instead of a bug.