Export Unicode glyph?

[James Gifford—NitroPress]

I have the feeling I've asked this before but I can't bring any answer to mind.

Is there any way to export a Unicode glyph-code directly to exported output (EPUB or HTML) without it being modified into text? I seem to recall some code, setting, override... something.

For example, if I put ࢐ in text and export it to EPUB, I get... "blah blah ࢐ blah blah" in the XHTML output. If I edit '&' to just '&' — boom, I get the left-arrow I wanted.

So is there any way to mark or flag that code for export without the modification? I feel as if I'm missing something, and that something may be "no, you can't do that." 🙂

I've discovered that if you cut and paste the actual glyph (from a symbols web page, for example) it may show a Dreaded Pink Box in InDesign, but seems to export exactly as desired. Looking for a better method, though.

ETA: I've also discovered there's a very peculiar little script in the Community folder (InjectUnicode.jsx) that can be configured to "inject" one or more Unicode characters at the cursor, but it has to be configured by renaming the script for each character or set of characters. Anyone have a more general implementation that, say, pops up a list of glyphs (configurable would be nice) or at least a code entry field, instead of being 2012-hardwired to one string?

[Robert at ID-Tasker]

"&#2192" is just bunch of characters - it will never be treated the way you want - you would've to change it to a desired glyph - displayed as such in InDesign - before export. 

FindChangeList.txt should work - but you'll have to create a list of all instances. 

Or a simple script can run a search - text or GREP - and insert those glyphs. 

Or probably autocorrect would work... 

[James Gifford—NitroPress]

Right, in a DM exchange with an author, we ran it down to cut-and-pasting the actual Unicode glyph in place, which results in a pink box some good part of the time. This will export perfectly (or at least has so far).

I was thinking, perhaps of some other app or process, that there was a way to "inject" raw code into export — can't something like that be done with Publish Online, for SVGs and blocks of HTML code? — but this bit of wonky magic doesn't exist for ID to EPUB. Just a matter of using font-based glyphs for print, PDF etc. and switching to direct Unicode glyphs for export. Not impossilble, just... demanding.

[Robert at ID-Tasker]

[...] Not impossilble, just... demanding.

By @James Gifford—NitroPress

Nothing is demanding anymore 😉 

[Joel Cherney]

I haven't touched EPUB export in eighteen months, but couldn't you style the arrow with a character style for print and PDF, then just delete the style before EPUB export? Or better, just reset the character style to base in InDesign, then add the corresponding style name to your CSS that gets appended in the "Additional CSS" list?

Because if you're getting the correct arrow in EPUB export when you export from a file with a pink-highlighted missing glyph, that means that the EPUB exporter is successfully adding the HTML character entity. Whatever method takes the fewest amount of clicks to get your document into that state with the pink highlight on the dropped arrow glyph, that's my suggestion, I think.  Maybe trying to specify it in the CSS actually isn't better?

[James Gifford—NitroPress]

I was working offlline with someone on this and ran through pretty much the whole gamut of options. While a couple of approaches will get odd glyphs into an ID doc for "printing" (simple solution: assign Symbola to a Character Style, move on), the only way I could find to get a Unicode character into the export was with direct representation (== pink box). Other than scripting, change lists and other doc automation, the only simple solution I can come up with for either/or (dual format) is to use conditional text.

CSS ain't here nor there for this, since it can only manage style changes, not content. (ETA: Hmm. Maybe a glyph styled with Symbola, CSS'ed to a generic font type... worth exploring. Hold, please.)

Odd little puzzle; I was sure there was a way to encode raw elements for export.

(And yes, using a font for these glyphs would export fine, without any further ado... if you export and embed the font, which is a negative practice for me, especially with something like Symbola, which is a 1 to 1.4MB face. So conversion/switch to native HTML glyphs is worth some effort.)

[Joel Cherney]

Yeah, conditional text seems like heavy lifting, here. Maybe I'm not getting why this pink boxification solution isn't the easiest:

I can tell you from memory exactly where to find the append-to-export field in Adobe Livecycle, despite the number of years it's been since I had to do so. Not sure about InDesign, though.

[James Gifford—NitroPress]

The only fault with the Char Style trick is that it's one way. How do you get back to a print/styled doc? (Since you can't un-set a Char Style font. I guess you could F&R between two Char Styles, though.)

The whole intersection of entering Unicode into ID is a bit maddening as well. But for the most part, this is a method to get some small number of special chars (from one up) into an EPUB export, not typeset whole pages of tensor calc.

But valuable input; let me test and refine according to my peculiar workflow standards.

[Joel Cherney]

The only fault with the Char Style trick is that it's one way. How do you get back to a print/styled doc?

Erm, uh, I suppose I hadn't thought of that possibility. Probably conditional text really is the most apt solution, then. Speaking of peculiar workflow standards, I tend to think of my print doc as the master document, and things like EPUB or interactive PDF exports as things that are target formats from which there is no return. That was honestly one of my takeaways from your EPUB frontmatter howto. Accordingly the INDD that is going to be the export-source for a given ebook or interactive PDF form might well be a file where I Saved-As with a new name like "Delete Me When You're Done.indd." 

[Dirk Becker]

CSS ain't here nor there for this, since it can only manage style changes, not content.

CSS can add content, as described for a list bullet here:

https://www.w3.org/Style/Examples/007/color-bullets.en.html

.

[James Gifford—NitroPress]

You're right; I'd forgotten this operation. It could be used in the gist of this discussion, but would have to be specific, per glyph. Which for a repeated element wouldn't be completely off the beam.

I'd just mildly argue that content really should be/needs to be in the document itself for all but a very narrow range of cases.

[James Gifford—NitroPress]

By Jove, I think that's it.

• Install Symbola or the mega-symbol font of your choice; you could use more conventional sets like Dingbats, Webdings or Symbol but it might be better (and have further reach) to use a specific "symbols" font.
• Create a Character Style named SYMBOLEXPORT or something, with characteristics as close to [None] as possible, especially a null font assignment.
• Dupe that style and name it SYMBOLA or FANCYDANCYGLYPHS or something. Make a simple change to Symbola font and leave all else null/default.
• While styling and formatting and building, use the latter style to highlight symbols entered using the Glyph panel (hint: Unicode has to be entered in hex, using your favorite glyph lookup tool if needed). These will now print and PDF-export in visible glyph form.
• For export to HTML or EPUB, do a simple F/R to replace SYMBOLA with SYMBOLEXPORT. All or most of your fancy glyphs will turn to pink boxes but will export to EPUB perfectly. DO NOT export fonts. No CSS needed (for this element anyway).
• As needed, use the reverse F/R (or just dump the converted but previously saved source file) to restore the visible glyphs.

(Technically, there's no need to do the switch to Little Pink Boxes, as exporting without embedding Symbola would have much the same result. But I find it cleaner and more transparent to remove that font completely from the export so that the glyphs are handled by the reader without looking for a font, or the wrong font, or otherwise getting too complicated at the reader/user end. You could also include a CSS statement to null out the Symbola assignment, without having to modify the export doc... something is making me think the actual doc fix has advantages but I can't put a finger on why. Much more extensive testing to come.)

Can't think of a more straightforward process, to manage this on a running basis, without extra tools, manual conversion, embedded fonts, etc.

Thanks for the insight here, Joel!

[Marc Autret]

(…) Anyone have a more general implementation that, say, pops up a list of glyphs (configurable would be nice) or at least a code entry field, instead of being 2012-hardwired to one string?

The InstantUnicode ‘responsive’ script may help — just type your codepoint in the form uHHHH and it instantly inserts the glyph at the insertion point:

https://indiscripts.com/post/2020/03/instantunicode-insert-characters-by-typing-their-codepoint

(Also supports code points beyond the BMP using the uppercase form U1HHHH.)

Hope that helps.

Best,

Marc

[James Gifford—NitroPress]

That's an excellent solution along the lines I was thinking — just making it all a little easier for those who use Unicode a lot. For simple projects, though, once you've looked up the Unicode value, just cutting and pasting the actual glyph is an option as well.

Thx!