Hi,
I have seen that _x000D_ has been an issuer some years ago. We did never have any problem with it, but know we get it more and more often when translating excel files. It shows up at the positions, where line breaks are in excel.
Can we somehow avoid it (without deleting the line breaks in excel)?
Best regards
Burim
Add soft line break to your segmentation rules (just in case you don't know - hexadecimal value 000D is a code for "linefeed", which Excel uses for linebreak inside cell)
It is used here for certain projects and it works fine, AFAIK (have not worked on that project for quite some time, so I just hope that it's still working fine).
Add soft line break to your segmentation rules (just in case you don't know - hexadecimal value 000D is a code for "linefeed", which Excel uses for linebreak inside cell)
It is used here for certain projects and it works fine, AFAIK (have not worked on that project for quite some time, so I just hope that it's still working fine).
Hi Evzen,
I think 0D is normally a carriage return, and a linefeed is 0A -- unless Excel uses something different from the usual standard, which, knowing Microsoft, is always possible ;-)
Best regards,
Bruce Campbell
ASAP Language Services
OMG, you're perfectly right, of course! Stupid me! Excel uses linefeed, I just mixed up the codes :-\
Right, then I really don't understand where does it come from... hmmm, does the Excel maybe have something to do with Access (pulling data via Access, or something)?
As they say here: stackoverflow.com/.../36216905
Excel uses line-feed character (ASCII 10) as the line separator, while Access uses the combination of carriage-return + line-feed (ASCII 13 followed by ASCII 10) as the line separator.
So I can imagine Excel not SHOWING the "extra" CR in the cell, but internally still having it there... and Studio then converting it to the typical notation when it encounters the character during parsing...
Hi Evzen,
You're right, it can get confusing when more than one program is involved and surprises should be expected :-)
For example, if I open a Word file in Studio that has soft line breaks (LF), then the Word soft line breaks show up as soft line breaks in the source segment in Studio.
But if I use the Windows clipboard to copy and paste the exact same text containing soft line breaks from Word into a target segment in Studio, the soft line breaks (LF) are converted to hard line breaks (CRLF) in Studio.
So when I wrote my Dragon commands to copy and paste text from Word to Studio, after copying a Word paragraph terminated with a hard line break (CRLF) to the clipboard, I had to first delete all the CR characters and then eliminate the trailing LF:
e.g. "text LF text LF text CRLF" in Word becomes "text CRLF text CRLF text CRLF" in the clipboard
after deleting all the CR characters this becomes "text LF text LF text LF"
eliminating the trailing LF gives "text LF text LF text"
which is what I wanted to paste into Studio.
Live and learn :-)
Best regards,
Bruce Campbell
ASAP Language Services
Translate
