Closed Bug 10816 Opened 25 years ago Closed 23 years ago

Add Unicode clipboard support to Mac

Categories

(Core :: Internationalization, defect, P3)

PowerPC
Mac System 8.5
defect

Tracking

()

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: tague, Assigned: nhottanscp)

References

()

Details

(4 keywords)

Attachments

(1 file)

add support for Unicode clipboard items to the Mac clipboard code
Status: NEW → ASSIGNED
Whiteboard: HELP WANTED
Target Milestone: M12
Target Milestone: M12 → M14
Here is more info
http://developer.apple.com/techpubs/mac/TextEncodingCMgr/TECRefBook-154.html
Naoki, since tague is pretty doom, is that possible you can also help him to
take care this issue ?
Assignee: tague → nhotta
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Who owns Mac clipboard code?
How do you propose to do this? There are no native unicode clipboard types on
Mac.
The document mentioned by ftang says 'utxt' has been added.
Summary: [PP] Add Unicode clipboard support to Mac → [FEATRUE][PP] Add Unicode clipboard support to Mac
Summary: [FEATRUE][PP] Add Unicode clipboard support to Mac → [FEATURE][PP] Add Unicode clipboard support to Mac
Keywords: pp
Change OS to Mac System 8.5
The URL have been change to 
http://developer.apple.com/techpubs/macos8/TextIntlSvcs/TextEncodingConversionMa
nager/TEC1.5/TEC.b4.html 
File Types

The file type 'utxt' has been registered for UTF-16 plain text documents. The 
(optional) scrap type 'utxt' is
also registered for UTF-16 Clipboard text.

Whether it is useful to register a file type or scrap type for UTF-8 text is 
currently under discussion. As do other
documents and text that use WorldScript encodings, plain UTF-8 documents could 
use the file and scrap type
'TEXT'. UTF-8 is compatible with the assumptions that govern WorldScript 
encodings; these encodings are not
specifically identified in 'TEXT' files and Clipboard contents.
OS: Windows NT → Mac System 8.5
For sample application support 'utxt' scrape type- download
ftp://dev.apple.com/devworld/Sample_Code/Text/TypeServicesForUnicode.sit
You need MacOS 9 to run that application. But the code in SampleWindow.cp show 
you the implementation.
Move to M15.
24010 is for more generic (non unicode) clipboard bug. Although this bug does 
not depend on 24010, I think it's simpler to wait for that to be implemented 
before doing this unicode specific case.
Target Milestone: M14 → M15
Keywords: helpwanted
Summary: [FEATURE][PP] Add Unicode clipboard support to Mac → [PP] Add Unicode clipboard support to Mac
Whiteboard: HELP WANTED
Summary: [PP] Add Unicode clipboard support to Mac → Add Unicode clipboard support to Mac
Target Milestone: M15 → M16
Is this supported by other apps?
My concern is that implement this may complicate the testing. And if not used by 
other apps then no benefit to do this.
So I am considering to move this to M20.
moving to M20
Target Milestone: M16 → M20
Target Milestone: M20 → Future
Keywords: intl
Isn't it time to upgrade it's priority? And fix this bug?!

This bug *prevents* -- in both mail/news, composer and browser -- (perhaps 
"editor" is the right module to target?) transport via the clipboard to/from 
external programs of any other text than *pur ascii*. I.E. if you try to copy 
some cyrillic text from any Mozilla module and paste it into a any mac editor, 
the cyrillic text is pasted in as a lot of empty spaces. 

The only "workaround" is to convert any text you want to import in Mozilla to 
html first. Or to save the Mozilla document as html first and then open the html 
document in for example IE or iCab and copy things from there.

Actually, I *think* the clipboard worked in Netscape6. But it has never worked in 
the post n6 Mozilla builds. At least not on MacOS 9.0, 9.0.4 or 9.1.
Keywords: relnote
Changing component:

"XP Toolkit also accepts bugs relating to copy/paste, drag & drop, key bindings,
the clipboard [...]"
Assignee: nhotta → trudelle
Status: ASSIGNED → NEW
Component: Internationalization → XP Toolkit/Widgets
QA Contact: teruko → jrgm
Bug #79864 may be a dup of this (it deals with copying ISO-8859-1 to the
clipboard).
->pink for triage, clearing future res.
Assignee: trudelle → pinkerton
Target Milestone: Future → ---
back to i18n
Assignee: pinkerton → nhotta
Component: XP Toolkit/Widgets → Internationalization
QA Contact: jrgm → andreasb
Sorry I did not respond earlier.

>Actually, I *think* the clipboard worked in Netscape6. But it has never worked in
>the post n6 Mozilla builds. At least not on MacOS 9.0, 9.0.4 or 9.1.
NS6 supports text in system charset for inter application copy/paste, i.e. you
need to have an localized OS.
Is the problem you mentioned above same as the one reported as bug 79864?
No -- unfortunately the behaviour fo Netscape 6.01 is the same as Mozilla of
todays build... 

And yes, I first filed a comment here before making my own bug report because I
supposed it could the same bug. And I still am inclined to think it is the same
bug. I think the answer laysl in what Frank Tangs has said, perhaps.
I modified my local build to put 'utxt' to clipboard code but nobody seems to
support it on MacOS 9.1. Other applications supports 'styl' (sytled text), I
think mozilla does not support 'styl'. With 'styl', text can be associated with
fonts then fonts can be mapped to scripts, so they can copy/paste without
depending on a system charset unlike mozilla.

I also tried MacOS X with 'utxt' enabled Carbon build. Apple's Mail supports
'utxt' also TextEditor (replacement of simpletext?). IE does seem to support it
but you can paste through TextEditor.
So I think it's worth to do it at least for OS X.
yup, that's all i was gonna do. r=pink.
>I modified my local build to put 'utxt' to clipboard code but nobody seems to
support it on MacOS 9.1.

I don't think that is correct. WorldText support it, as far as I now. So does
the free Simple Unicode Editor (SUE), soe does Style. And there is also a
TextEncodingConverter OSAX (TEC.OSAX) that support it.

And even if WorldText uses utxt internally [it at least saves text as utxt],
there is no problem copying to e.g. NisusWriter or SimpleTExt from WT and
vice-versa. I suppose the clipboard is converted when one move between 'styl'
and 'utxt' apps. And I suppose the same thing could/should happen in MOzilla?

I think it's worth to do it also for OS 9.1 because a) I believe apple's
WorldText support it (you find it on the 9.1 CD though perhaps not on the update
CD). And b) because the current situation is so bad. Mozilla is fine as a
browser in the literal meaning of the word. But without clipboard support, it
really ain't working.

Thanks for the info. It's a generic patch, not risticted for OS X.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
I am here inserting some info I just received from my programmist friend from
Poland. He has some info which might be relevant, but he was to busy to log into
the Bugzilla system (He wrote this text about Bug #7986, but due to its
technical nature I include it here instead):

[snip]
Hello,

Leif asked me to take a look at this bug [Bug #7986] and I can confirm he is right. 
Text conversions in Mac OS do not depend on what localized version of 
Mac OS you use. The general engine for conversions is called Text 
Encoding Converter (TEC). You may take a look at my program "Cyclone" 
which enables conversions of text from many encodings. I have never 
heard that it is not working properly in Russian, Polish, Hebrew or 
American English Mac OS. It is simply unrelated. Proper display of the 
text is another story and requires language kits.
Whether you use TEC in Mac Mozilla, or you use some internal converter 
engine you should not assume that the only language available to user is 
the main language of operating system and you should not base the 
conversion on this information. When you know the input encoding, let's 
say it is a ISO Latin 2 (Central European) you are supposed to convert 
it to Mac CE regardless of Mac OS localization. You say you use Unicode 
text for internal operations, that is great, why don't you put 'utxt' 
clipboard flavor in addition to 'TEXT' flavor?. This way Unicode-enabled 
applications would be able to use Unicode text directly and not 
reconvert it.
My programs are available at:
<http://homepage.mac.com/tkukiel/>
SUE (Simple Unicode Editor) project is available with sources. SUE is 
able to import and export text with help of TEC. I do not deal with 
clipboard in SUE because it is all done by Multilingual Text Engine on 
which SUE is based. You may use the sources for text conversion if you 
want. If you need the sources for clipboard conversion from Cyclone, I 
may open it as well, but it is very similar to file conversion which is 
available in SUE.

Regards,

Tomasz Kukielka
tkukiel@mac.com

Sorry, I meant referring his note to Bug 79864
I am including yet some other comment about how some programs handle utxt on the
clipboard. From Tomasz:

On Friday, May 11, 2001, at 02:17 , Leif Halvard Silli wrote:

> Perhaps you could tell me (or better: THEM) if/that WolrdText, SUE and 
> Style are using utxt on the clipboard?
Regarding WorldText and SUE - I am not sure what Apple does in MLTE. I 
know there was a bug in early version of MLTE that prevented from 
reading 'utxt' clipboard format. About Style - it would be the best to 
ask Marco, but I guess it tries to read 'TEXT' with 'styl' first, and 
then if it is not present, it reads 'utxt' (which is without style 
information). If I may guess, MLTE does the same. Actually I think it 
should be done the other way: 'utxt' should be "preferred" since we do 
not know if 8-bit text carries correct, but this is not acceptable for 
WASTE an MLTE because you lose style information.
Cyclone supports 'utxt' in a sense that if you convert clipboard from 
Unicode it takes 'utxt' flavor first and when you convert to Unicode 
(16-bit of course) it puts 'utxt'.

Tom
I forgot about WASTE, yes that is used in 4.x. I heard about MLTE that replacing
TE in OS X. Since mozilla has its own text widget, I don't think we going to
replace it by MLTE. Anyway, in case there is an enhancement request, please file
as a separate bug, thanks.
WASTE <URL http://www.merzwaren.com/ > is free for freeware apps. WASTE 2.0 is
moving towards MLTE functionality, btw. It is used in iCab, and mac OE/IE but
was not especially successfull in Communicator I think... I'll consider filing a
bug for *real* style support but WASTE as such is not important. However, to get
it right: MLTE is allready here, in 'Mac OS 9.x': SUE uses it. As does
WorldText. As does MLTE-demo from merzwaren.com.
sr=blizzard
checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Changing QA contact to ylong@netscape.com.  Yuying, can you verify this?  Please 
let Frank know in case you need more information regarding verifying this bug.
QA Contact: andreasb → ylong
Tested Build 2001051508 (don't know if the fix is included there?) trying to
copy cyrillic text in Mozilla and paste into WorldText [WT]. If I select and
copy *only* cyrillic text (no ASCII including *no* spaces, commas, dots etc),
then the cyrillic text will be pasted into WT. But as soon as I also include
ascii text the behaviour is as befor. However, I think I have not tested
selecting only cyrillic characters in earlier builds, so it could be that this
is nothing new.
I now tested the same thing in a build from 9th of may. And there not even
copying just Cyrillic worked. Hence I draw the conclusion that the fix has been
checked in in todays test build but that it ain't working... - yet.
There is a regression caused by this checkin bug 81028. And I think paste from
other app will not work without that fix. So please wait for that to be fixed
for verification.

I don't have WorldText, does it supports 'utxt'? From the comment of 2001-05-11
12:21, not clear if it supports it or not.
Anyway, verification can be done by using MacOS X with TextEdit or MacMail.


Yes, WorldText support 'utxt'. Select "view Clipboard" and you will see info
telling you if the content is unicode.  If you have OS 9.1 full install CD, you
will find WorldText in CD Extras folder. Else, try MLTE demo from
<http://www.merzwaren.com/bin/mltedemo-10a3.sit>. SUE unfortunately does not
have "view clipboard".
You refer to bug 81028, but drag and drop works... as long as the text is from
iso-8859-1 range.

Also, WorldText tells me that:
- cyrillic text only is copied as Unicode Text (unformatted). This works.
- cyrillic + ascii is copiead  as formatted text *and* formatted unicode text.
  But this does not work. Only ASCII part is copied.
  This is in my view a logical consequense of Mozillas lack of styl support.
  I suppose that if also the ASCII part is copied as unformatted unicode text,
  this could work. So, please: either turn off formatted text copyiing or hurry
  up and fix bug 79864. 
- ascii/iso-8859-1 text is copied as formatted text and formattd unicode text
  And this works. And this is also logical and obvious.
reassigned QA contact
QA Contact: ylong → marina
*** Bug 78039 has been marked as a duplicate of this bug. ***
I am using BBEdit Lite 6.1 on Mac OS 9.0 : the copy/paste work for non-ascii
Latin-1 chars. Cyrillic chars re turning into question marks (???) Does BBEdit
Lite support "utxt"? I'll reopen. Leif, please comment on this , nhotta is on
vacation.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Hi Marina, I'm not sure about unicode status of BBEdit *lite*.
According to my testing with Build ID 2001083110
one *cannot* copy *from* Mozilla *to* unicode aware editor (like WorldText). But
the reason for this is ??as it was before-- that WorldText prefers styled text
over Unicode text. And since copying inside Mozilla (still) places both a layer
of  UNicode text and styled text on the clipboard even if the styled text is not
usable, WorldText receives the  cyrillic text as question marks. While editors
which prefers unicode text over styled text, has no problems whatsoever. An
example on a such editor is Pepper and also --I think-- BBEdit full version.
Leif, thanks for the prompt reply. So my understanding is that this "fix' that
i've  undone and resolved the bug "reopen" will fix only cases when editor
prefers styled text over Unicode text, all other scenarios will fail ( and
display ???), right?

Hi, Marina.I belive that it is the opposite. When the editor prefers *unicode
text* over styled text, things will work. When the editor prefers *styled text*
we will get questionmarks, even if the editor is Unicode savvy. And the reason
for this is to be find in another bug: the lack of support for (multilingual
text via) styled text.In fact, the question marks is something I believe nhotta
fixed. He made it so that non-ascii text is copied to the *styled text* layer
(of the clipboard) as question marks, as a kind of warning that there is an
encoding problem. The unicode layer (of the clipboard) is untouched by this, so
that if you paste the same text into a different unicode aware editor that
prefers utxt, things will work.

In my opinion the styled text layer is totally useless. Hence in my view Mozilla
should only skip the styled text layer on the Mac platform. At least any text
with non-ascii text should not be copied as styled text. It just makes it more
incompatible that it in needs to be. Just think about the WorldText case.
WorldText is a unicode aware editor. But it also understand styled text. And it
does so because it needs to be compatible with old editors. Mozillal doesn't
have the ability to work with old multilingual editors *at all* until it gets
styled text support. So why make oneself imcompatible just by that useless
styled text layer?
Leif, thanks very much for this comprehensive clarification. Using TextEdit on
Mac OSX i was able to paste into the Editor cyrillic strings and display them
correctly as well as japanese.Even those strings that had non-ascii and ascii
chars were pasted just fine. And i agree with you that the styled text layer is
useless..Now it looks like BBEdit lite prefers styled text over unicode and my
undersatnding is with old editor copy/paste from mozilla won't work. So i am
marking this bug as fixed for now ( even though there will cases when paste
won't work)
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
verifying with 2001-09-12 build on Mac OSX
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: