Annotation of kupu/doc/FAQ.txt, revision 1.1.1.1
1.1 dwinter 1: ===============================
2: Kupu Frequently Asked Questions
3: ===============================
4:
5: * Will this work with Safari or Opera or ...?
6:
7: No, Kupu will only run on browsers with the IE engine (IE 5.5+) or those
8: with a Gecko engine (Mozilla 1.3.1+ and Netscape 7.1+), not on the
9: Konqueror one (which Safari uses) or on Opera or any other browser.
10: Actually Mozilla copied a feature unique to Internet Explorer, which is
11: not part of any standard, which Kupu uses. Because it's not part of a
12: standard, it is not very likely any other browsers will implement it,
13: although we keep hoping some day they will.
14:
15: * Kupu allows users to do all kinds of things - like coloring text -
16: that I don't want in my system.
17:
18: All of the kupu style functions can be turned on and off using CSS or in
19: the configuration. Additionally, the element controls can be extended to
20: accomodate special needs of your content.
21:
22: * Is my platform supported?
23:
24: It probably is: Kupu has requirements on the client side, but works with
25: just about any web server. As long as your server supports POST and some
26: server-side scripting language or CGI (to process form variables if Kupu
27: is part of a form) or HTTP PUT you can install Kupu on your website or
28: application.
29:
30: * Why do I get all kinds of weird characters?
31:
32: Kupu seems to work correctly when you use UTF-8 as the character set for
33: encoding, but gives unpredictable results when you use another one such
34: as latin-1 (ISO-8859-1). Make sure to always use UTF-8 as the character
35: set for incoming data and set the correct Content-Type header or meta-tag,
36: and Kupu will send back UTF-8 data.
37:
38: * Saving seems to work, but my browser keeps showing old stuff
39:
40: Browsers tend to store web pages a while to reduce the amount of data that
41: has to be transferred. Obviously this can get in the way when using Kupu,
42: so the browsers need to be told not to store (cache) the Kupu iframe contents
43: on retrieval. This can be done either with HTTP headers or with meta-tags.
44: For an example of which meta-tags to use, see fulldoc.html (the example
45: content page).
46:
47: * What's this '1223' status code I see in the code?
48:
49: There seems to be a bug in Internet Explorer that in some cases it says that
50: the status code of a save action is '1223' (a code that doesn't exist in
51: HTTP, it's not described in the specs and there seems to be no information
52: about this on the web). Since it looks like this code is only returned on a
53: succeeding save action, it seems that reasonable safe work-around is to add
54: the status code as one of the allowed codes in common/kupueditor.js (search
55: for '204' and you'll find a line that checks if the status code is either 200
56: or 204, add 1223 there). This is what we've done, however, if you find
57: something can go wrong with that workaround, please let us know.
58:
59: * Does Kupu produce valid XHTML?
60:
61: Well... Kupu produces *well-formed XML*, which out-of-the-box does not
62: contain any elements that aren't allowed in XHTML anymore, and are written
63: in a form compliant to the XHTML notation (lowercase tag and attribute
64: names, attributes all have values and all values are in quotes) but it is
65: theoretically possible to create constructions that are not valid according
66: to the XHTML DTD. For most cases, however, the data produced by Kupu is
67: perfectly usable, even after copied from another website or notorious Word.
68:
69: * What about i18n?
70:
71: Currently Kupu is not adapted to i18n. The plan is to write i18n support for
72: the JavaScript sources in one of the next versions (probably using XML
73: inside the HTML, a technique sometimes called 'XML data islands', to store
74: all the JavaScript strings) but currently it's not possible to convert the
75: JavaScript strings on the server without having to hack in the sources.
76: Current technologies make it hard to handle i18n in a clean way on the
77: client, so therefore Kupu will at first choose to let the server take care
78: of it. Since Kupu is not dependent on a specific server, however, we can not
79: guarantee that support for your server will be available even in the future,
80: but we will at least provide infrastructure and probably also dictionaries
81: for different languages.
82:
83: * What about Bitflux, Xopus, and others?
84:
85: The authors of these editors have done great work. They are superb
86: applications, but the major drawback is they work in only one browser (as of
87: this writing). Kupu was created to work in both Mozilla/Netscape and Internet
88: Explorer.
89:
90: * What's with the xsltproc error when 'make'ing kupu?
91:
92: xsltproc wants to load external entities references in the XML
93: files, such as DTDs. External entities that are referenced by URIs
94: are typically loaded when you have a network
95: connection. Alternatively, you can install the DTD on your harddrive
96: and point xsltproc to an XML catalog that resolves the URIs to local
97: harddrive directories.
98:
99: Most users that generate the kupu macros probably don't have the
100: DTDs installed on their harddrive. When they invoke xsltproc, it
101: will load them from the net. If you don't have an internet
102: connection, you'll see the above error.
103:
104: To stop xsltproc from getting resources from the net (because it is
105: time consuming and unnecessary), we pass it the --nonet switch. A
106: bug (?) in xsltproc makes it then complain about not being able to
107: load entities from the net--but that's exactly what we want to
108: achieve! So, this error message is not an error message for us--it
109: is the contrary!
110:
111: Other questions
112: ---------------
113: Additional questions for the FAQ are welcome. Please post them on:
114: kupu-dev@codespeak.net
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>