InDesign: typing characters misery

Andreas Stötzner's picture

This is the kind of miserable behaviour I . H A T E .

I am to insert various PUA characters in the text, either via a customized keyboard or the glyph palette. In the case of *some* characters they only appear when getting typed if a certain other character or a space precedes it. E.g., one particular char. doesn’t show up when I want to insert it just after a paranthesis. But ID seems then to insert some kind of dead character, which you notice when pressing the delete key. There is no OT fancies turned on. ID playes a game of cat-and-mouse with me and I don’t see why.

I have no clue about what I am doing wrong this time.

– it is not the font
– it is not the keyboard driver (which works fine generally)
– no dead keys or combining sequences involved
– all works perfectly well in TextEdit.

Has anyone a clue to this?

Nick Shinn's picture

Sorry, all I can suggest is clearing caches, emptying trash, rebooting your computer, and generating the font again.

riccard0's picture

It could be a problem of encoding. I noticed that TextEdit and InDesign don't play along well in this regard.

Andreas Stötzner's picture

I have restarted. Same problem now.

Nick, clearing cache in ID? where –? Never done before.

> Encoding: which kind of encoding problem could it be?

When I type a space just before the char. in question, it shows up. When I then delete the space, the char. vanishes and the space remains.

I’m running mad.

riccard0's picture

which kind of encoding problem could it be?

Dunno, but the symptoms are similar to those of the headers here on typophile, where one non ascii glyphs not only isn't displayed, but "eats" one or more adjacent characters.

Nick Shinn's picture

Andreas, search for "AdobeFnt" and delete the numbered files, e.g. AdobeFnt07.lst -- but DO NOT DELETE the ".db" files!

Andreas Stötzner's picture

"AdobeFnt" and delete the numbered files

I did so and re-started.
Same thing.

I trashed all instances of the font, re-started again and re-edited the font (its a .ttf).
Same thing.
While I’m still testing in ID, the program crashes. Very odd.

I’ve sent an Absturzbericht to Adobe now. Yes its that dark.

I sorted out the ch.s belonging to plane 1, those belonging to PUA. Much PUA ch.s in the very font behave totally normal. Some do not.
I still don’t understand what the problem can be.

Andreas Stötzner's picture

Is there something in the Konsole to look for?

Andreas Stötzner's picture

I am using slots from F830 to F88F (not all of them).
These positions make trouble:
F860, F861, F862
F870, F878, F879, F87A, F87B, , F87C, F87D, F87E, F87F

If you happen to use fonts with that codepoints, do you experience something similar?

John Hudson's picture

This may not be the issue, but it is always worth checking for possible conflicts between PUA usage by major software developers. For example, I note that at least some of the problem codepoints you list are used by Apple:
http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/CORPCHAR.TXT

# The block of 32 characters 0xF860-0xF87F is for transcoding hints.
# These are used in combination with standard Unicode characters to force
# them to be treated in a special way for mapping to other encodings;
# they have no other effect.
#
# 0xF870-0xF87F are "variant tags" - they are like combining characters,
# and can follow a standard Unicode (or a sequence consisting of a base
# character and other combining characters) to tag it so that it will be
# unique, treated in a special way for transcoding. These always terminate
# a sequence of combining characters.
#
# 0xF860-0xF86B are "grouping hints" - they precede a group of two to
# four standard Unicode characters to indicate that they are treated as a
# group for transcoding. This grouping overrides any other combining
# behavior.

Andreas Stötzner's picture

John, thanks a lot. This looks like the kind of hassle I was suspecting.
It was obvious that this is an ID handling fault.
I already thought there might be only one option: to leave that part of the PUA.

However, I still wonder: when Apple does use that area in that particular way, why do things run well in Apple’s own TextEdit but not in Adobe InDesign? (Not that I would wonder about such a coalition between A. and A., but its neither very fair nor very clever. And not *private* at least.)

evertype's picture

I have had the same problem using a font of my own with PUA characters in this range. In ID CS4 I used the Unicode Hex Input keyboard, and could type F860, F861, F862 but after that I did not get glyph entry.

No problems in Quark. Love Quark. :-)

Syndicate content Syndicate content