In the last few days I have had a couple of clients contact me saying that they are having some uppercase "L"'s appearing in places on their website. Upon investigating, I found that there were some random ETX characters on their websites. They are showing up on the websites on Windows (definitely on Chrome, maybe on other browsers too), but in Firefox on Mac I can see them in the source code. On Chrome on Mac I can't see them anywhere. Here are pictures of the problem:
picture of the issue
source code
My clients websites have not been updated in months so I'm guessing that Windows pushed out an update in the last week to the default language/encoding which is making these show up now.
Removing them is easy, but I wanted to understand where they are coming from and how I can avoid the problem in the future. It looks like the characters are in text that I would have copied out of Photoshop. Is there any easy way to sanitise and remove these kind of characters when I copy from Photoshop or other similar programs?
As I mentioned earlier, I am on Mac, using Chrome primarily. Is there any way to get Chrome to actually show these characters so that I can see if they are appearing?
You are correct that the issue is with Photoshop. Line breaks (Shift+Enter) are encoded in Photoshop as an ETX character (end of text), not an LF (line feed) or CRLF (carriage return + line feed).
These characters can be seen by pasting your content into a plain text editor such as Sublime Text. The find/replace function should make removing them easy.
I don't believe there is any way to get the ETX characters to display in Chrome for Mac.
However, since the characters are still present (even if they are invisible), you could select all the text on the page (Mac: Cmd+A / Win:
Ctrl+A) and paste it all into Sublime Text to find them.
Related
I am just learning how to code, so this may have an obvious solution, but I have searched for answers for a few days now. Several characters at the end of the alphabet (x,y,z, etc.) are not appearing in the actual website despite it appearing in my code. for example in HTML I will type "Last year was my senior year" and my website will say "Last ear was m senior ear"I have insured that I am using utf-8 (unicode) on both platforms and have re-written the code many times. Any help would be appreciated, and an image of the problem will be posted as well.
html code on left, website on the right
In your software, you could try to look for a "Display invisible characters" preference, maybe there's one somewhere around the missing letter that is the cause of your issue?
I sometimes have such issues when I accidentally do a fine space (alt + space on Mac) rather than a normal space. That sounds impossible but actually happens when I write code too fast, when I insert a space after or before characters such as [] or {} that require using the alt key...
Oh, this seems to be a Google Chome/font problem: https://support.google.com/chrome/thread/2892761/the-letter-y-is-missing-on-some-pages-i-can-look-up-the-pages-in-another-browser-and-they-display-fine
I resently found out that in chrome you can highlight text in the link. This can be done by adding #:~:text= to the link. Example: This link does not highlight anything while This link highlights my chosen context. Since I discoverd this I'm using it all the time for showing somthing to a colleague.
My question is what is the browser suport for this? And if I try to highlight a whole paragraph it doesn't work, so what is the limmit?
I searched for a while without anny sucess.
Edit
After long trying i found that there is not a spesivic limit to this. It stops at a dot F.E. This is will work. and if i go farther like This won't bequse the text im searching goes trough after the first dot!
Edit 2
Having another look at the documentation I saw that you can add a begin and end preifelx. When useed you can select a whole paragraph like This.
[For ongoing detailed browser support information: Scroll-To-Text Fragment support on Can I use]
Well, after some obscure googling I got this
TL;DR - it's a very interesting chrome-specific feature Scroll To Text Fragment. As mentioned here there is no support in other browsers, albeit IE/Edge is in "public support" state (as they say, it used to be in IE5). Documentation is here, and I don't see any size limits. Maybe the problem is in line break/begin-end paragraph special symbols handling?
UPD: other idea: there was a limit on GET-request length - 2,048 characters. Now it should be bigger, but maybe chrome still somehow cut/doesn't process too long URLs?
UPD2: The first guess is right. This link to wikipedia works, albeit this, only one character more, doesn't. The problem is in 0A/0D "carrage return/line feed" characters: if they are present in text, even encoded, highlight won't work at all. Possibly it's a bug and should be reported to Chrome, but still. Good thing for checking this is to paste selected text in Chrome "Search" tool: if it doesn't find pasted text and you see some strange characters - whoopsie.
On my site I am using the Google Font Roboto. I noticed in several places the following:� or what I call a question mark in a black diamond. (Does this symbol have a name?)
I typically see this when a font doesn't have a character it can render, however, this doesn't appear to be the case in this instance. It happens in a few instance. One of them is when there is an extra space the other I have seen is when I use the § symbol.
I tested Roboto using the § symbol with a type tester and it works just fine.
Why doesn't it work on my site? What is going wrong?
I am unsure why this is happening and would still love an answer but I found a solution that I am using in the mean time.
It appears to have have happened with content that was copied into my text. For spaces or other symbols were this appears (such as - or / I am just retyping the character. For the § symbol I replaced it with the HTML character § (or you can use §) and this has solved the issue.
I'm observing this super weird bug on a news site maybe someone has seen before.
In the html text, if the first characters in a line of text are numerals, they are not displayed by the browser.
The html is coming through via a CMS, which forces the line breaks in the editor, but no tags are inserted. CMS data is XSLT processed into html templates.
When this text is sent to the browser, you can see the new lines are formed (without br tags), and you see that the numerals are still within the content. But these new lines are only honored by the browser if a white-space property is set using one of the "pre" values.
Seems to be related to the white space property as i can use the inspector to add white-space:pre-line/pre-wrap and boom, they appear.
Really keen to hear some thoughts on this, or could this be a possible Chrome bug?
Link to an example article here:
tvnz.co.nz/national-news/flights-cancelled-130km-h-winds-hit-wellington-5508294
In the last paragraph of that article you can read/inspect to see the missing numeral values.
So I really don't understand why this happens, but it has something to with the zoom setting... There are all kinds of articles about chrome bugs w/ the zoom setting, but none seem to address exactly what you were seeing...
If you inspect the page and change the zoom from 1 to .99999 it works... Again, I got the suggestion from this link but I'm at a loss to explain exactly what is broken w/ chrome, but it does seem like a chrome bug...
I have been working on a subtitles engine for flash/flv video player. On my Mac everything is great, nice aliased glyphs, displaying all the characters, etc. Switch to windows, it all goes out the window. Some machines with Eastern Characters enabled display fine, but I can't guarantee all users will have this option selected.
I am using the TLFTextField, I am pulling in UTF-8 XML with Chinese/Japanese characters.
I have tried embedding the (required fonts/glyphs) but pushes the file size up massively.
I have also tried changing it to unicode, with no joy. Has anyone got any experience with displaying these characters while maintaining a low file size.
I'm not really offering a solution to your question, but if the user is wanting Chinese or Japanese subtitles, I'm pretty sure that they will have the correct encoding.