This may be a Product Issue
will want to know this info:
Product and version (e.g. FileMaker Pro 14.0.3)
OS and version
Browser and version (for WebDirect only)
How to replicate
Workaround (if any)
Thank you for your response, but I am sorry I didn’t quite understand what you had in mind ... are you recommending that I should go open a thread in the other forum that you posted the link for?
The problem in question occurs in my current version of FileMaker Pro Advanced (15.01.119) running on a Mac Book Pro with OS 10.11.16. But the line-break problem after these characters has existed on all version of FM that I have used (going back about 8 years now), and on all machines (all Macs) that I have had, so it’s not related in some important way to the version or OS, as far as I can see.
posting to Product Issues is a way to see if Tech Support may have more information on this. You may be able to move this to that space.
1 of 1 people found this helpful
200D is ZERO WIDTH JOINER.
"(" & Char(8205) & "text" & Char(8205) & ")"
Thanks for the idea, but I just tried inserting uni200D between the open parenthesis-like character and following character.
No change. The line break is still there. Zero-width joiner does nothing.
I also tried zero-width joiner to the left of right-parenthesis-like characters and it also does not inhibit the unwanted line break.
Was this merely a suggestion or has it worked for you specifically?
Or is your reply intended to suggest that I must write a calculation to rectify the problem in every instance?
Sorry, I seems did bad test on calculation field and table view.
Did you check at file option "Use Asian language line-breaking" ?
Thanks for the suggestion.
I tried all combinations of checking and unchecking “Use Roman language line-breaking” and “Use Asian language line breaking”.
It makes no difference: the line breaks are still in the wrong places.
What happens if you insert a byte order mark, e.g. Char ( 65279 ) immediately after the bracket? According to Wikipedia,
If the BOM character appears in the middle of a data stream, Unicode says it should be interpreted as a "zero-width non-breaking space" (inhibits line-breaking between word-glyphs). In Unicode 3.2, this usage is deprecated in favour of the "Word Joiner" character, U+2060. This allows U+FEFF to be only used as a BOM.
Just remember to account for the BOM if you do any processing on the value later on to avoid unexpected results.
I hope this works for you.
Just out of curiosity...
what is the Default Language setting for the field in Options for Field (Storage)?
Oops, sorry, I didn't see that User19752 suggested pretty much the same thing up-top.
Thanks for the suggestion. I also tried u+FEFF but it also did not affect the line-breaks.
I tested the problem in a field which had English as the default language setting. I changed the setting to “Unicode” and it did not make any difference. I can try setting it to some Asian language or RTL language maybe, but I don’t think it will change anything. If it does I’ll post again about it.
Thanks. That probably helps narrow down for TS too. I appreciate that you tried.
Sent from miPhone
For what it's worth, using your examples above I was able to get the string to not break by using ‹ and › (Command+Option+3 and Command+Option+4) on the Mac instead of the unicode character.
« and » are Option+\ and Shift+Option+\
...couldn't find easy equivalents for your other symbols.
Would a dedicated mathematical symbol font solve your problem?
Thanks again for your advice.
You’re entirely right that not all parenthesis-like characters have the problem I mentioned, but in FM many of the less commonly used ones do.
You’re talking about
U+2039 (U+203A) SINGLE LEFT- (RIGHT-) POINTING ANGLE QUOTATION MARK
U+00AB (U+00BB) LEFT- (RIGHT-) POINTING DOUBLE ANGLE QUOTATION MARK (= guillemet aka “guillemot”)
These do not have the line-break problem. It’s just that they are used in my database for other things already. They are used as punctuation in French and sometimes German, for example, and are not angled brackets.
The choice of font can’t make any difference unless it’s what they call a clip font (one which puts the “wrong” symbols in other Unicode points). If I used a clip font, then yes, I could substitute “⟨” for “‹”, But I also need “‹”, so I don’t want to do that, since then I’d also be substituting “⟨” for “‹” in the wrong contexts.
Besides, my project is committed to Unicode-compliance, so I am just not using any clip fonts at all.
In my current implementation I do make various graphical substitutions as a stopgap, but in some cases there simply is no alternative (e.g. the tortoise shell brackets — of all varieties — do not have non-breaking near-equivalents in FM).
I can use non-breaking Greek letter DELTA (U+03B4) instead of line-breaking Latin Small letter Delta (U+1E9F) but the result is not attractive because, in some of the fonts that I need to use, the Greek letter is slanted, and the Latin one isn’t, so you end up with words with an incorrectly slanted delta in the middle. This is why the two have distinct unicode points.
Unicode, after all, was supposed to allow us to stop having to make these inadequate substitutions.