nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

TS671SP1+P1: & #160; in VFE fields

Adam Stoller

Environment

the source and fix of the problem (I searched throgh the manual for "160" and "insert" with no real joy). If not, the "masking" "fix" will have to suffice.

Find more posts tagged with

Comments

ISCBorisB

I'm not sure why but what gets added by VFE for empty lines are actually two characters, not one, 0xC2 0xA0 (or 194,160 in decimal).

Btw, circumflex Â(194) is the first one, 160 is   If that's acceptable in your case, you can remove Tag, for whatever reason this garbage goes away with it.
Needless to say, that would not change DCRs that have been already saved, extra characters are real, not just VFE Dispaly rendered

[html]

p

SPAN

[/html]

Adam Stoller

I'm not sure why but what gets added by VFE for empty lines are actually two characters, not one, 0xC2 0xA0 (or 194,160 in decimal).

Btw, circumflex Â(194) is the first one, 160 is   If that's acceptable in your case, you can remove Tag, for whatever reason this garbage goes away with it.
Needless to say, that would not change DCRs that have been already saved, extra characters are real, not just VFE Dispaly rendered

[html]

p

SPAN

[/html]

Hmm - well, I don't know enough about how the various folks at this site compose their content in the VFE field to know if there are other P tags that might be needed within the body of the text - so I think we'll stick with the "masking" fix for now and just make sure the encoding is set to UTF-8.

Thanks.

ISCBorisB

Hmm - well, I don't know enough about how the various folks at this site compose their content in the VFE field to know if there are other P tags that might be needed within the body of the text - so I think we'll stick with the "masking" fix for now and just make sure the encoding is set to UTF-8.

Thanks.

Please note that configurational change I've proposed is quite benign, it'll remove empty Paragraphs only (I haven't emphasised that originally).
Something like Ghoti will not be affected. If however your Contributors use empty Paragraphs for formatting - tough luck

Adam Stoller

Please note that configurational change I've proposed is quite benign, it'll remove empty Paragraphs only (I haven't emphasised that originally).
Something like Ghoti will not be affected. If however your Contributors use empty Paragraphs for formatting - tough luck

Ah - I was confusing it with one of the other entries that removes tags if they don't have any attributes - thanks for the clarification. If I have time tomorrow (my last day on-site) I might try it out - if I do, I'll post the results.

DougD

The is a non-breaking space. The encoding should be utf-8. It's not masking any problem. The two bytes mentioned are the non-breaking space character encoded as UTF-8. The "A" character only appears when the encoding is not utf-8, which is mismatch in encoding.

BTW, there should be one 'remove' tag, which can have multiple tags within it.

Adam Stoller

The * is a non-breaking space. The encoding should be utf-8. It's not masking any problem. The two bytes mentioned are the non-breaking space character encoded as UTF-8. The "A" character only appears when the encoding is not utf-8, which is mismatch in encoding.

BTW, there should be one 'remove' tag, which can have multiple tags within it.

wrt to the remove tag - yes, that makes sense.
wrt to masking problems - you're wrong - the problem is that the characters are getting inserted without any intention by the user, and by ensuring that the pages are rendered with UTF-8 encoding it masks the fact that those characters were inserted.

Thanks anyway.

ISCBorisB

wrt to masking problems - you're wrong...

DougD's Avatar implies that he's coming from Ektron side - and the issue we discuss just *might* be the TS-Ektron implementation glitch,
not the bug in eWebEditPro per se (interim DCR Repository between HTML Editor and the Target Page, etc)

ISCBorisB

The two bytes mentioned are the non-breaking space character encoded as UTF-8

Ah! I should have guessed... Bare 0xA0 (single byte greater than 0x7F) is not valid UTF-8.
Thanks for the explanation!

DougD

ghoti, perhaps I misunderstood the problem. My explanation addressed the problem where non-breaking spaces are displayed as "A". Non-breaking spaces are sometimes inserted in order to retain regular spaces in circumstances where the document object model (DOM) would remove regular spaces, such as inserting HTML. It's an unfortunately necessary inconvience, but preferrable to having a space removed.

Adam Stoller

ghoti, perhaps I misunderstood the problem. My explanation addressed the problem where non-breaking spaces are displayed as "A". Non-breaking spaces are sometimes inserted in order to retain regular spaces in circumstances where the document object model (DOM) would remove regular spaces, such as inserting HTML. It's an unfortunately necessary inconvience, but preferrable to having a space removed.

As it happens, I didn't have time to try the configuration changes that were suggested, so this thread will likely end up in limbo.

I'm not sure I understand why a WYSIWYG editor would need to insert characters on its own, simply because a user chose to edit that section of the content - and certainly don't understand why it would be configured thusly out-of-the-box (though it's questionable whether that's Ektron's box or Interwoven's box in this case) - however, the point may be somewhat moot as I no longer have access to the environment in which this issue arose.

DougD

This explanation is not likely to provide satisfaction because it does not fix the problem. Hopefully, however, it will shed more light on the situation. The Visual Format editor is built on the IE editing engine (i.e., mshtml.dll). The IE engine has an observed defect where leading and/or trailing spaces are sometimes lost when calling the DOM pasteHTML method. The workaround in the editor is to replace leading/trailing spaces with a non-breaking space, which is not lost. The effect is that some spaces are converted to non-breaking spaces. This workaround is coded in the editor; it's not configurable. A non-breaking space is better than no space at all.

If the non-breaking spaces are a problem, you can write some code to replace all non-breaking spaces with regular spaces. This would, of course, remove all non-breaking spaces intentionally inserted by the author, so the nbsp button should be removed in the visualformatconfig.xml file.

-Doug

Adam Stoller

This explanation is not likely to provide satisfaction because it does not fix the problem. Hopefully, however, it will shed more light on the situation. The Visual Format editor is built on the IE editing engine (i.e., mshtml.dll). The IE engine has an observed defect where leading and/or trailing spaces are sometimes lost when calling the DOM pasteHTML method. The workaround in the editor is to replace leading/trailing spaces with a non-breaking space, which is not lost. The effect is that some spaces are converted to non-breaking spaces. This workaround is coded in the editor; it's not configurable. A non-breaking space is better than no space at all.

If the non-breaking spaces are a problem, you can write some code to replace all non-breaking spaces with regular spaces. This would, of course, remove all non-breaking spaces intentionally inserted by the author, so the nbsp button should be removed in the visualformatconfig.xml file.

-Doug

Thanks for the explanation - it sounds like a valid description of the situation I was seeing while on site (which I'm not anymore) - and it's nice to have the background information.

JessicaD

TS671 SP1
Windows 2000 SP4

Thank you for the explanation about the & #160s. It helps to know why it is happening, but it is still an issue for us. In addition to developing DCRs using DCTs, we have single-sourced code snippet DCRs that have the forced additional spaces at the end of the code for the snippet links (not empty paragraphs). Here's what the end of a snippet should look like:

[html]Snippet Link SPSx11960

[/html]

VFE is adding a space and the & #160 at the end of the snippet so it looks like this:

[html]Snippet Link SPSx11960 & #160;

[/html]

(I had to add space between the & and the # to show the code).

We've added code to the presentation templates that removes the & #160s, but when the XML is generated, it still throws an error unless the space and & #160 is removed manually. This is extremely time-consuming for the content developers, especially since in one product alone, we have more than 2,000 snippets.

What are the chances that this will be fixed in a service pack or upcoming release, and when can we expect that? Alternatively, when can we expect that TinyMCE will allow us to add custom buttons (we would have transitioned to it when we upgraded to 671, but we have customer buttons that apparently can't be included in TinyMCE)?

Tanuj

Jessica I had the exact same issue, I don't remember what all i changed to fix it. But 2 things are for sure, if possible take the latest new version visualformatconfig.xml then customise it again as per your needs then trying to fix your old visualformatconfig.xml trying to make it work in new vfe.

other setting I think which helped me was this charencode


clean charencode="entityname" cr="cr" lf="lf" showonsize="5000" preferfonttag="false" reducetags="true" showdonemsg="true" prompt="true" hideobject="true" mswordfilter="true" feedbacklevel="2">
   remove>
    tagWoAttr>SPAN/tagWoAttr>
   /remove>
   xsltFilter src="[eWebEditProPath]ektfilter.xslt" />
  /clean>

if you can send me your visualformatconfig.xml then i can help you more.

Tanuj

JessicaD

Thanks for the feedback. I attached our visualformatconfig.xml file (in a zip file) as you requested.

One other thing to note - we've tried modifying the config file to use cleanhtml, but it causes our links to break. Using cleanhtml adds http://serverIPaddress/ to the beginning of every relative link, so none of them work. We removed cleanhtml and it's fine now.

In any case, I'm still curious about whether or not Ektron has plans to fix these bugs.

DougD

The non-breaking space is a workaround for the bug in IE, so I don't know of another solution other than to write some custom script to remove the space following your custom tags. An XSLT or regular expressions should work fine.

BTW, what is the XML error you are seeing. The non-breaking space should not cause an XML error. Perhaps the XML error was caused by publish="cleanhtml" or charencode="entityname". Neither of these should be used with version 5.1.

Tanuj

Try this file.

nico

so what was the solution?

scandorph

Alternatively, when can we expect that TinyMCE will allow us to add custom buttons (we would have transitioned to it when we upgraded to 671, but we have customer buttons that apparently can't be included in TinyMCE)?

TinyMCE supports custom buttons since 6.7.1SP1. Check the forms pub dev guide for more information on how to enable them.

Adam Stoller

so what was the solution?

In my case - there was no solution per se - because I didn't get around to trying to resolve this while I was involved in the particular project.

If I run into the problem again, I'll look at this thread (hopefully I'll be able to find it ;-) and try to verify the proposed solutions.

Spencerspins

Does anyone have a case or bug number for this? We are having the same issue and planning to report this as a bug. (TS 6.7.1 SP1)