Closed Bug 100425 Opened 23 years ago Closed 23 years ago

Need to support display of license or readme files in Mac OS X

Categories

(SeaMonkey :: Installer, defect)

Product:
SeaMonkey
Component:
Installer
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.6

People

(Reporter: slogan, Assigned: jj.enser)

References

Details

(Whiteboard: [PDT+] [OSX+] [ETA 09.26])

Attachments

(5 files, 1 obsolete file)

patch file
5.64 KB, patch
Details | Diff | Splinter Review
EULA.rsrc.sit - contains resources used by ShowEULADialog().
346 bytes, application/octet-stream
Details
Take 2, add 'EULA' resource, read name of EULA.txt out of the dialog's title.
10.62 KB, patch
Details | Diff | Splinter Review
Stuffed "EULA.txt" into DLOG's title.
361 bytes, application/x-stuffit
Details
N6.2 EULA .txt file with paragraph breaks
17.08 KB, text/plain
Details 
 
Over to simon to express how we do this. Simon, put what you know here and then
assign back to me.
Keywords: nsbranch+
Whiteboard: PDT
Target Milestone: --- → mozilla0.9.5
This is how we decided to add support for showing a EULA in Mozilla:

1. Early during startup, we put up a native dialog that contains the EULA
   in a scrolling text box, and OK/Cancel buttons.
2. If the user hits the OK button, we write a resource to the Mozilla binary
   to indicate that the EULA was accepted.
3. Subsequent runs check that resource, and run without showing the EULA.

I propose that the resource should be 'EULA' ID 0.

In more detail, the process of showing the splash should be as follows:
1. Check for EULA 0, if it exists, skip the following.
2. Read the name of the EULA file from a 'STR ' resource.
3. Attempt to locate the EULA file on disk; if it fails, bail.
4. Put up a native dialog with scrolling text box and OK/Cancel buttons
5. Read the EULA file into the scrolling text box (32k limit?)
6. Use ModalDialog event loop to wait for user confirm or cancel.
7. On user confirmation, create 'EULA' 0 resource as an empty resource, and 
continue.
8. Tear down the dialog. If the user canceled, ExitToShell().

Issues:
* This adds native UI that might need localization. What should the dialog look 
like? Does it need any strings other than OK/Cancel buttons?
* This adds code that runs at every startup, that imposes some (slight) risk.
* The code needs to run on Mac OS X only.
OS: other → MacOS X
Hardware: PC → Macintosh
Over to syd for first cut at implementation
Assignee: sfraser → syd
QA Contact: bugzilla → ktrina
what if we can't write back to the app for some reason (it's on a CD or in a 
read-only application folder owned by root)? We should run in that configuration, 
or is that totally impossible these days anyway?
Status: NEW → ASSIGNED
1. For any text that may be needed to add to the dialog, I will cc: robinf in
documentation.  I wonder if we need text that says "If you do not accept the
license, click Cancel." or something like that.  Robin, do you know?

2. Does the license file have to be formatted in any special way for this
dialog?  We get the license file as text files, I think.  Have to check.

3. If a user upgrades to a later Netscape/Mozilla version, will s/he still see
the license file for the newer version?   (assuming we still present the license
in this manner).

Thanks for the prompt work on this!
if we implement it the way we're planning, yes, they will see the license when 
they upgrade as it is tied to the application binary, not a profile.

however, they will see the license again if they install another copy of emojo on 
the same machine and run that. i guess that's ok, just that no other apps do it 
that way.
Whiteboard: PDT → PDT [OSX+]
Need legal approval for this implementation.
Re: ------- Additional Comments From lchiang@netscape.com 2001-09-19 11:14 -------

>1. For any text that may be needed to add to the dialog, I will cc: robinf in
>documentation.  I wonder if we need text that says "If you do not accept the
>license, click Cancel." or something like that.  Robin, do you know?

Instead of OK/Cancel, I think the button to accept should be labeled "Accept",
and the button to decline should be labeled "No". We should include text that
says "Click Accept if you accept the terms of the license agreement. If you
click No, setup will quit." mlemley, can you please review?

>2. Does the license file have to be formatted in any special way for this
>dialog?  We get the license file as text files, I think.  Have to check.

The text does need to be wrapped such that it fits in the dialog without
requiring the user to horizontally scroll. mlemley supplies the EULA as a text
file, which may need to get wrapped to fit in the Mac dialog. Please see
bugscape bug 8853.


why not "Accept" and "Decline"? That would make sense. "No" doesn't make any 
sense to me.

You have legal approval for the implementation.

Rather than OK/Cancel, there must be an "Accept" button.  I also think "Decline"
makes sense for the other button.  

There should be text in the dialogue box right above the buttons that
explicitely states:

Click "Accept" if you agree to the terms and conditions of the Agreement,
otherwise click "Decline" and Setup will exit.

If you let me know what the margins of the Mac dialogue box are, then I can set
those in Word and save the Word file as "text with hard breaks" in order to
provide a .txt file in proper line-wrapped format.

Also, can someone let me know if there is a size limit (I saw "32K limit?") and
whether the dialogue box for Mac can display an extended character set (e.g.
french accent characters).
The Mac Toolbox code can handle the text wrap ok so that isn't a problem.  
Accented text is OK except I think the Mac and PC differ on some high-ASCII 
characters so you'll wnat to pre-flight it.  Keeping the text length under 32K 
characters is definitely preferable but it can be worked around if necessary

well, the workaround for > 32K is to use WASTE, and we so don't want to go there. 
Let's make sure we keep it under 32K. 

Just to inject a little mozilla-ness into this bug (we are in bugzilla, 
afterall), what license will the mozilla version show? Is there one? Is this 
applicable to mozilla?

Syd - Status pls ...
Whiteboard: PDT [OSX+] → PDT [OSX+][ETA 09.25]
Attached patch patch file — — Splinter Review 

    
    

    
  
this patch doesn't compile under carbon. many data structures are now opaque or 
non-existent.

the patch also needs an extra newline at the end to apply.


    
    

    
  
since you never create the storage for your DocumentRecord, casting the windowptr 
to a DocumentPeek then dereferencing things off the end of it starts corrupting 
the heap. i'm pretty sure that's why it crashes. If you're going to piggy-back 
the data, you need to tell GetNewDialog where to create the structure so that 
space is allocated for your DocumentRecord.


    
    

    
  
Taking per macdev meeting decision.
Assignee: syd → beard
Status: ASSIGNED → NEW

    
    

    
  
Thanks for taking this Patrick, let me know if there is need to test build this
on Mac OS 9 (I've got a tree, and can easily do this)

    
    

    
  
I'm just about ready to check in a fix for this. Patch coming.

    
    

    
  
Responding to Mike Lemly's question, yes the TextEdit code I am using 
allows you to display french or other european character sets. I am 
assuming that whatever localization is done will correspond to the Mac's 
system script. In addition, the display routines can support style 
information if you like. To make a localized EULA.txt file that contains sytle 
information (and is <32K), copy styled text from your favorite word 
processor into a new file using SimpleText, which will store the style 
information as a 'styl' resource.

    
    

    
  
Adding Montse to cc: list as beard's forthcoming comment is going to have I18N/
L10N implications


    
    

    
  
Some comments:

What about the EULA resource? Don't we need that (or something) to determine if
the file was already displayed on first launch? We don't want this to show each
time.

Just a reminder that sfraser suggested that we read the EUAL file name from a
STR resource (instead of hardcoding it into a FSSpec definition). 

Patrick, thanks for all of this work. 

    
    

    
  
What about having the .smi show the EULA?


    
    

    
  
Now that the coding is out of the way (for the most part), I tried a little
experiment with the Disk Copy utility. It turns out that one can write an
AppleScript that directs Disk Copy to convert a disk image (compressed or
otherwise) into a "self mounting image" (.smi). Then, opening up one of Apple's
.smi files, such as "Startup Disk 9.2.1.smi" with ResEdit, I discovered that it
contains some extra resources that provide a way to display a license agreement
before the disk image is mounted. Here's what I found:

Type  ID    Name
CNTL  5000
DITL  5000  Legal DITL
dlgx  5000DLOG  5000  Legal DLOG
infn  5000
LPic  5000
STR#  5001  German
STR#  5002  English
STR#  5003  Spanish
STR#  5004  French
STR#  5005  French
STR#  5006  Italian
STR#  5007  Japanese
STR#  5008  Dutch
STR#  5009  Swedishstyl  5001  German
styl  5002  English
styl  5003  Spanish
styl  5004  French
styl  5005  French
styl  5006  Italian
styl  5007  Japanese
styl  5008  Dutch
styl  5009  Swedish
TEXT  5001  German
TEXT  5002  English
TEXT  5003  Spanish
TEXT  5004  French
TEXT  5005  French
TEXT  5006  Italian
TEXT  5007  Japanese
TEXT  5008  Dutch
TEXT  5009  Swedish
If I copy all of these resources to a new .smi file that I construct, then my
.smi file when launched will display the legal agreement dialog. The dialog
contains a popup menu that includes all of the languages listed above, and the
'STR#' resources contain localized strings for all of the controls/buttons in
the dialog.

Finally, if one of these .smi files is launched under Mac OS X, the Classic
support system doesn't get launched, instead the Mac OS X version of Disk Copy
gets launched, and it shows the EULA dialog. I think we should strongly consider
using this mechanism rather than adding some new code to present this dialog.

The only downside to using this mechanism is that it is undocumented, and Apple
could stop supporting it in the future. However, as an interim, low cost
solution, that works on all released and soon to be released versions of Mac OS
X, this is a pretty good solution. Comments?
Status: NEW → ASSIGNED

    
    

    
  
Syd, you're right, I haven't put in the code that adds the 'EULA' resource. Read
my comments about .smi files and resources. I will add that code if we decide we
don't want to go the .smi route.

    
    

    
  
Here's what I was trying to type before, but NS6.1 let me down:

Resources that are required by the .smi:

Type  ID    Name
CNTL  5000
DITL  5000  Legal DITL
dlgx  5000
DLOG  5000  Legal DLOG
infn  5000
LPic  5000
STR#  5001  German
STR#  5002  English
STR#  5003  Spanish
STR#  5004  French
STR#  5005  French
STR#  5006  Italian
STR#  5007  Japanese
STR#  5008  Dutch
STR#  5009  Swedish
styl  5001  German
styl  5002  English
styl  5003  Spanish
styl  5004  French
styl  5005  French
styl  5006  Italian
styl  5007  Japanese
styl  5008  Dutch
styl  5009  Swedish
TEXT  5001  German
TEXT  5002  English
TEXT  5003  Spanish
TEXT  5004  French
TEXT  5005  French
TEXT  5006  Italian
TEXT  5007  Japanese
TEXT  5008  Dutch
TEXT  5009  Swedish



    
    

    
  
I urge everybody to look at Patrick's comments with the time stamp of 2001-09-25 
18:21 and voice their opinion.  I think adding the EULA to the disk image for 
display is a much cleaner/simpler solution than modifying the Mozilla/N6 app to 
do it.


    
    

    
  
Well, doing that (this diskimage hack) does lock us into having to install the
bits that way. The original plan decouples us from the mechanism by which the
bits get delivered, thus making it (how we install) more flexible to change.

    
    

    
  
Re: ------- Additional Comments From robinf@netscape.com 2001-09-19 16:24 -------
> 
> Re: ------- Additional Comments From lchiang@netscape.com 2001-09-19 11:14 -------
> >2. Does the license file have to be formatted in any special way for this
> >dialog?  We get the license file as text files, I think.  Have to check.
> 
> The text does need to be wrapped such that it fits in the dialog without
> requiring the user to horizontally scroll. mlemley supplies the EULA as a text
> file, which may need to get wrapped to fit in the Mac dialog. Please see
> bugscape bug 8853.

Actually, the EULA text will look better if each paragraph isn't wrapped. The
text box I'm using does wrapping itself. This lets us modify the size of the box
without having to rewrap the EULA text. Just put hard line breaks between
paragraphs.


    
    

    
  
jumping in with my $.02, i think using DiskCopy to display the EULA is the right
thing.

    
    

    
  
adding more i18n/l10n people; thanks for the heads up!

    
    

    
  
Passed 09.25, what's the new ETA?

    
    

    
  
syd, look at it this way:

The disk image hack involves no code change.

It only affects installs of the OS X version which is the only build we're 
currently planning to distribute in that format.

It doesn't involve writing to the app's resource fork.  I noticed on re-reading 
some of the OS X docs last night that that is frowned upon (primarily due to 
issues with having write access to the directory containing the app but that may 
change in the future).

As I've said before, I think it's a much cleaner/simpler solution and both Simon 
and I would have suggested it but for thinking the .smi format wasn't OS X 
native.  Kudos to Patrick for discovering it.


    
    

    
  
Adding jj, as he's most likely the one who will do the packaging. JJ, would you
weigh in on with your opinion? Are there any Apple tech notes describing this
feature (displaying a license agreement from a .smi)? We should ask somebody at
Apple.

    
  
Keywords: patch
Whiteboard: PDT [OSX+][ETA 09.25] → PDT [OSX+][ETA 09.26]

    
    

    
  
Wow, lots fo reading here to catch up with :-/
So here are my comments/questions:
1. does adding the EULA dialog code to an .smi file serve the same purpose as
   having this code in NS ? IF we go for one (or the other), does this mean we
   don't need the second implementation ?
2. We were planning on packaging OSX into a .img file, not .smi since .smi will
   launch classic. Is that not a problem?
3. In the .smi scenario, can the EULA content come from a file on disk rather
   than a TEXT/styl resource? That will make release & localization work easier
4. wrapping & charset: That has already bitten us in the past. The license as
   it shipped with 6.1 is checked in as a hard-wrapped latin1 file and without
   any extended char so that it displays fine on all platforms. This is most
   likely what we'll use for OSX as well.
5. I will try to find out with Apple if the "EULA dialog on .smi mount" feature 
   is documented somewhere, but I think we can proceed since Patrick figured it
   all out :-)

    
    

    
  
> ------- Additional Comments From jj@netscape.com 2001-09-26 12:55 -------
> 
> Wow, lots fo reading here to catch up with :-/
> So here are my comments/questions:
> 1. does adding the EULA dialog code to an .smi file serve the same purpose as
>    having this code in NS ? IF we go for one (or the other), does this mean we
>    don't need the second implementation ?

You got it. We don't need the code if we can stick the EULA into the disk image
file (a .smi).

> 2. We were planning on packaging OSX into a .img file, not .smi since .smi will
>    launch classic. Is that not a problem?

No, it's not a problem, because Mac OS X special cases these applications, and
launches the Mac OS X version of Disk Copy, which handles the dialog display
itself.

> 3. In the .smi scenario, can the EULA content come from a file on disk rather
>    than a TEXT/styl resource? That will make release & localization work easier

I don't believe so, it must be in a resource. It's trivial to copy and paste
these resources with Resorcerer et. al.

> 4. wrapping & charset: That has already bitten us in the past. The license as
>    it shipped with 6.1 is checked in as a hard-wrapped latin1 file and without
>    any extended char so that it displays fine on all platforms. This is most
>    likely what we'll use for OSX as well.

Hard wrapping is fine until it isn't. If the window is too narrow, or the font
metrics differ on various systems, hard wrapped text becomes ragged and awful.
I'd argue for using SimpleText formatting for this purpose (only put carriage
returns at the end of paragraphs). I'm fine with sticking to ASCII/latin1.



    
    

    
  
we like it. let's get all the EULA translations, and make sure we have a URL to
the japanese license agreement on site.

JJ - Do you have everything you need to fix this bug? We think you are the owner
of this one.
Whiteboard: PDT [OSX+][ETA 09.26] → PDT+ [OSX+][ETA 09.26]

    
    

    
  
Michele/Richard - We need translations of the EULA as soon as possible.

    
    

    
  
Reassigning to me.
Release automation will grab the license from the usual location
(mozilla/LICENSE for mozilla and ns/xpfe/global/resources/content/license.txt
for netscape)
and turn it into a TEXT resource as part of the packaging process.
Patrick, I might need to work with you to get the proper additional resources
you listed. 

For L10n, according to Patrick's earlier comment, appropriate STR# and TEXT
resources will have to be added to the .smi files with localized UI strings and
license text.
Assignee: beard → jj
Status: ASSIGNED → NEW

    
    

    
  
Who needs translations of the EULA asap? Don't those go into the localized
product only. Currently we don't have plans to have the EULA ready until 10/8
since we know it always changes up until the last minute. Is the EULA final now?

    
    

    
  
The N6.2 Eula is finalized and was attached to bug 8853.  

Note that the file attached to 8853 is a .txt file with hard breaks on each line
suitable for display by the Windows dialog box (which does not automatically
wrap the text).  The file for the Mac OS X build, from what I have read in this
bug, should be the same text, but should be .txt with hard breaks only at
paragraphs.

I will attach the N6.2 license text with paragraph only breaks to this bug.

The license text includes a line of French with accent characters toward the end
of the file (which raised the question at one time as to whether it was a length
of file problem or character set problem since the file loaded properly after
the last portion was removed).

    
    

    
  
adding rchen

    
    

    
  
Msanz - Can you respond to Michele's question in this bug?

    
  
Whiteboard: PDT+ [OSX+][ETA 09.26] → [PDT+] [OSX+] [ETA 09.26]

    
    

    
  
I just sent her and Richard a message. I think it's nice to have all
translations in the US package, but if that is not possible due to deadlines,
then we should include US only in the US build and avoid dependencies. 10/8 is
too late, so that means Japanese license cannot be in the US build. Richard, any
update in European ones?

    
    

    
  
I'll check with our translation agency to see if we can get the ja EULA sooner
than 10/8. But I won't know that until at least Monday 10/1. More info to follow
then.

    
    

    
  
Concerning translations:
The ONLY change to the EULA text from N6.1 to N6.2 is the version number.  The
substance of the text did not change.  We should be able to put "6.2" in place
of "6.1" for the translations that were previously used.

    
    

    
  
We have completed a diff between the 6.1 & 6.2 EULA's and can only find 2 minor 
changes.  So, from a localisation standpoint, if we can confirm that there will 
be no changes to the EULA before RTM , then we just have to modify the version 
numbers.

    
    

    
  
packaging automation is ready to be updated with the "popup" license dialog.
Test build has been delivered to internal ftp (currently displays the Netscape
EULA).

ftp://sweetlou.mcom.com/products/client/seamonkey/macos/10.x/ppc/2001-10-01-04-0.9.4/MozillaforMacOSX.smi.bin

btw, how come Netscape 6.next EULA is posted as an attachment to this *bugzilla*
bug?

Oh, and speaking of that EULA, "Netscape 6.1" is still mentioned 4 times. I
fixed this in my test build.
Status: NEW → ASSIGNED
Depends on: 100168

    
    

    
  
jj, it's probably not showing the icon because the plst isn't being found. for
packages, it needs to be a stand-alone text file, not embedded in the app. this
file currently lives in 

mozilla/xpfe/bootstrap/mozilla.plst (and netscape.plst in the ns tree)

I forget where it has to live, but probably in the top-level of the package. Not
sure why it doesn't run.

I like the license agreement on the .smi. pretty slick.

    
    

    
  
according to "Inside MacOSX: System Overview" the bundle needs to have the file
"Info.plst" (the mozilla.plst that is checked into the tree) in the Contents
folder. So it should look like:

- MyBundle
  - Mozilla (alias to Contents/MacOS/Mozilla)
  - Contents
    - PkgInfo
    - Info.plst
    - MacOS
      - Mozilla

PkgInfo contains the type/creator codes of the app. It is redundant according to
the docs, but is necessary for quick lookup by the finder (to avoid reparsing
the plst every time).

    
    

    
  
adding the PkgInfo file (with the contents "APPLMOZZ") gave us an icon in the
finder, but not the nice 128x128 one. I keep running into problems where the
finder thinks the "Contents" folder is busy, so it's grayed out. I think that's
why it won't pick up my plst. Not sure.

    
    

    
  
working on adding info.plist & PkgInfo files to the OSX package.
A new packge will be delivered soon.

Jaime, Sol,
Since the license is now displayed every time the disk image is mounted, do we
need to include the license agreeement as a text file next to the application ?
(in comparison, for OS 9, the license file is next to the installer, but doesn't
get installed with the product)

So far, the only icons in the netscape folder are:
- Netscape (application bundle)
- Read me file
- Profile Manager
- Profile Migration

    
    

    
  
JJ: As long as the user must see and agree to the license upon installation of
the product, and there is some path back to the license for future reference
(e.g., go to "Help | About Netscape 6" and click on the "license" link), then I
think we are OK. I'm not sure if that is what you are describing.

    
    

    
  
We will deliver the JA EULA to JJ by the end of today. We'll also attach a copy
of it this bug then.


    
    

    
  
Sol: Thanks, you answered my question. User can definitely get to the license
again the way you said (about page, license link), or every time the disk image
will be mounted on the desktop. (just like it shows up every time the user
launches the OS9 installer). So be it. No license file on disk.

Michele: I got an email from Richard Close (Ireland) with FR, DE and ES
licenses. (but no JA). Am I supposed to include all of these together with the
English one inside the US-English disk image ?


    
    

    
  
JJ - yes as I understand it you're supposed to include all the localized license
agreements from Ireland and from me (JA) in the US- English disk image. But
maybe Sol or Montse can confirm this since I only heard it from them. 

    
    

    
  
Montse: Do you know how we exposed localized licenses to users of 6.1? I do not.

    
    

    
  
I believe the localized licenses appeared in the localized releases only. I
don't think they've ever been in the US build before... but I could be wrong...
Montse -  would know for sure.

    
    

    
  
they haven't been included in the US builds before. We thought it'd be nice to
include them since the dialog supports multiple langs. Sol, what do you think,
should we?

    
    

    
  
I'd prefer to follow the simplest path at this point. If it is simpler to only
include the US-English license with US-English builds, let's do that. If it's
simpler to include the localized licenses, let's do that.

I do recall that we had problems at some point when the application was
"choking" on the non-ASCII characters in the localized licenses. France requires
a paragraph to be included in French in order to bind French people to the terms
of the license, so we included the paragraph, but converted all non-ASCII
characters (e with an accent) to ASCII. 

I just want to be sure we don't run into that issue if we attempt to display
localized licenses to US-English users.

    
    

    
  
It's not more complicated to have some localized licensed added to the packaging
process, as long as the list and content don't change too often :-)

We'll have to put a process in place so that L10n people can freely check in
changes to the localized license in the ns tree so that Release builds pick them
up automatically, but right now the texts I already have will be stored on the
OSX build machine in a resource file that only I can access & update.

I received via email The EULA localized for FR, DE, ES and JA.
As indicated above (2001-09-20 06:13), Each license should be < 32K. JA is
currently 34K and should be reduced to fit that requirement.
(one way top cut it in half is to remove the English license from the JA doc
even though it has always contained both languages)

I'll include what I can next time I repackage the OSX disk image. (probably
tomorrow)

    
    

    
  
Have we tested that the EULA _has_ to be <32K for the disk image trick?  I know 
ResEdit can't handle a TEXT resource >32K but I believe Resorcerer can.


    
    

    
  
It's not a ResEdit/Resorcerer limitation, it's a limitation of the TextEdit API, 
no?


    
    

    
  
who said it was an resource editor limitation ? It is a TextEdit limitation as
Patrick said in his comment of [2001-09-25 15:14].

Patrick, any idea why Japanese is always greyed out in the language menu? (even
with a non-empty TEXT/styl resource) ?
I've ssen that during testing under 9, haven't tried under X yet.

    
    

    
  
You don't have a Japanese capable system. It's greyed out on OS 9 for me, but on
OS X it works fine.

    
    

    
  
We don't know for sure the code that displays the license for disk images is 
TextEdit based under Mac OS X but I just checked and it durn sure is for Mac OS 9 
(put more than 32K of text in that resource and you crash with a corrupted heap).  
Oh well, time for a shorter JA EULA


    
    

    
  
We currently have the problem Steve mentioned with JA and the workaround has
been to ship the US one (legally binging anyway) and provide a link to a page
for the translation as a courtesy. I'd recommend bundling the European ones

    
    

    
  
There's no way to shorten the JA EULA. It's a direct translation of the US EULA.
I guess we'll have to leave the JA one out of the US build.

    
    

    
  
We always bundle English together with Japanese EULA because of the legal 
issue. But for OS X, since all languages will be available for users, I think 
we can remove English text from the Japanese EULA, for OS X only. Thus, the 
size will be way smaller.

    
  
Blocks: 102989

    
    

    
  
I agree with Ying-Lin about the redundancy of the English text since the user
can switch on the fly to read the license in several languages. 

However, I tested the 34K JA license undex X and it doesn't crash and the entire
text seems to be displayed. Only problem I see with my 10.0.4 system: the text
is displayed as single byte. (no japanese glyphs)

    
  
Target Milestone: mozilla0.9.5 → mozilla0.9.6

    
    

    
  
whoa! we need this on the branch. this is a PDT+ and OSX+ bug. why are we moving
it out to 096?

    
    

    
  
No worries, this will be in 6.2 regardless of the tfv.

Current status is that I have a "tentative" automation that creates a disk image
for OS X which pops up a dialog with the license agreement in English, German,
French, Spanish or Japanese.
Only problem so far is that the japanese text is displayed as garbage (header
and buttons ARE displayed in japanese)

fyi, today's NS6.2 for OS X deliverable is here:
ftp://sweetlou/products/client/seamonkey/macos/10.x/ppc/2001-10-04-04-0.9.4/Netscape6forMacOSX.smi.bin


    
    

    
  
I work with jj today in his cube and once we create a 'styl' resoruce for the
japanese TEXT resource and associate a font id with Japanese range (sorry, I for
get the font id number, but I think jj know, it is docuemnt in the Inside Mac -
Text page 1-50) it display Japanese license without problem. 

    
    

    
  
fixed. Mozilla EULA (English) added to the disk image in todays' build,
available here:
ftp://ftp.mozilla.org/pub/mozilla/nightly/2001-10-11-04-0.9.4/MozillaforMacOSX.smi.bin
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
Someone raised a good question which should be addressed --
How and where should Netscape license text be checked into the Netscape builds
and where should a Mozilla EULA be stored (which raises another question of what
should be in a Mozilla EULA for presentation to Mozilla end users -- which
should not be the same as a Netscape EULA).

Perhaps it is not a clean technique for us to attach a Netscape license text to
a Mozilla bug.

What text is in the Mozilla build referenced by jj?  If it is from the Mozilla
trunk and not Netscape branch, then the license text should not be the Netscape
license.

    
    

    
  
I'll answer Mike's questions here, but any follow-up to this discussion should
take place outside of this bug, which is about including the license agreement
dialog (whatever its content is) into the MacOS X disk image.

Mozilla EULA comes from
mozilla/LICENSE, on whatever branch/trunk the rest of the source gets pulled from.
Netscape EULA comes from
ns/xpfe/global/resources/content/license.txt

    
    

    
  
Verified on build 2001-10-11-04-0.9.4 (using Netscape6forMacOSX.smi.bin)
Very cool!
Status: RESOLVED → VERIFIED

    
  

        Attachment #50806 -
        Attachment is obsolete: true
Product: Browser → Seamonkey

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: