 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/5/2012 0:54, Invisible wrote:
> Can you name one single text editor which can actually change character
> encoding based on a mere XML encoding specification?
I expect you could set up vim to do it, since you can set it up to recognize
Python, Bash, etc.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> On 26/02/2012 12:35 AM, Darren New wrote:
> > On 2/25/2012 2:37, Orchid Win7 v1 wrote:
> >> For example, to say "this XML file actually contains XHTML", you're
> >> supposed
> >> to add something like 5 separate headers, each about 25 million miles
> >> long,
> >> to the top of the file. Why? Would one header not be sufficient?
> >
> > Really? What do you have to add? I suspect you exaggerate a bit.
>
> First, you must say
>
> <?xml version="1.0" encoding="ISO-8859-1" ?>
Gaah! No! Use UTF-8! 8859-1 is Western European/United States only! Any
characters that are not in this set will be rendered as ? or worse. UTF-8 gives
access to the whole of the Unicode codeset, so no data will be mangled by the
encoding. Sorry, I'm a big proponent of using a more universal character set,
especially when handling data.
>
> Which is fair enough, although the 5-digit ISO code number isn't exactly
> easy to remember. Then you have to say
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
>
> Yeah, I'm really going to remember that without looking it up. :-P No,
> you can't just say "this is XHTML". You really do have to write all that
> crap. And after /that/, you still have to say
>
Yeah, the DTD is a bear; what you do is set up a starting point and use that so
you don't have to remember the DTD all the time.
> <html xmlns="http://www.w3.org/1999/xhtml">
>
> Um, didn't I just declare this as XHTML already? At least this URL is a
> bit shorter, I guess...
>
You set a doctype processing instruction that gives a web browser information on
how to handle your document, remember, HTML comes in many different flavors.
Your xhtml document is an xml document. The xmlns attrubute is specifying that
this document should conform to the specifications of the xhtml standard. I
think this is actually optional, but allows better validation. This uses an xsd
file which defines the schema.
> In short, that's a /hell/ of a lot of typing, before I've even written
> my document. It's also a lot of typing that I have to go look up on
> three different websites every single damned time I want to write XHTML.
Meh. You create a starter file and copy that when you want to do an xhtml file.
> >> Then there's all that stupidity with character entities. It should be
> >> possible to include character entities in /all/ XML documents, not just
> >> XHTML. But to this day, I have never discovered a way of doing this.
> >
> > You have to declare the entities. Otherwise, you run across &frump; and
> > don't know what it means. That's what DTDs are for.
>
> So why isn't there a DTD somewhere that contains all the entities that
> everybody uses, which I can just link to? More to the point, since
> everybody uses the same set of entities, why aren't they built in?
>
Because sgml is a standard that allows a large amount of flexibility in what it
actually is.
> >> One of the nice ideas of XML is that you can use namespaces to include
> >> one
> >> sort of XML document inside enought - e.g., you could put an SVG file
> >> inside
> >> an XHTML file. But nooo, apparently you need a specialised DTD to do
> >> that.
> >
> > You can. Of course, your various processors have to know what the
> > various namespaces *mean*, so you have to declare them and you have to
> > have a processor that understands them (which is where the DTDs come in).
>
> You would /think/ you could just say "hey, this stuff here is in the
> XHTML namespace, this stuff here is in the SVG namespace", and that
> would work. But it doesn't. You need to use a DTD specially written for
> the exact combination of XHTML+SVG. To me, this indicates that the
> system is fundamentally broken. It should not be necessary to write a
> separate DTD for every possible combination of XML documents imaginable.
> You should just be able to refer to the DTD for XHTML and the DTD for
> SVG and have it work.
Thing is, the DTD and schema can be defined anywhere. That's why all of the
clunky URL's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <lef### [at] freefr> wrote:
> Le 23/02/2012 10:11, Invisible a écrit :
> > This still leaves me with the problem of how to generate unusual
> > characters in the first place. Typing → is pretty simple. Figuring
> > out how to actually generate the arrow character is not.
>
> You just need the right documentation.
> Either you search it each time on the web (like "utf-8 chartable"... )
>
> or you call it correctly, and ask for unicode (utf-8 is one
> presentation, unicode is what you really want), and get to print the
> parts that you need often.
>
> See http://unicode.org/charts/
>
> And soon you will discover that there is no single font to display all
> possible unicode glyphs.
>
> You also need a unicode-compatible editor...
Code2000 comes close for Plane 1... The higher planes are a different story
alltogether, but most of those are rather specialized anyway.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford <no.### [at] spamme> wrote:
> > <?xml version="1.0" encoding="ISO-8859-1" ?>
> Gaah! No! Use UTF-8! 8859-1 is Western European/United States only! Any
> characters that are not in this set will be rendered as ? or worse. UTF-8 gives
> access to the whole of the Unicode codeset, so no data will be mangled by the
> encoding. Sorry, I'm a big proponent of using a more universal character set,
> especially when handling data.
Nothing stops you from using &#xx; codes regardless of the encoding.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> OK, so I've written a program that generates a bunch of XML as output.
> If you open that in a web browser, it shows up as a simple parse tree.
> Which is OK, but a little verbose.
>
> Fortunately, using the wonders of XSL (specifically, XSLT) you can have
> the browser transform the raw XML into a pretty-looking XHTML document.
>
> But *only* if you edit the original XML file to mention the XSLT file
> that you want to apply.
>
> Now, it ought to be simple to write a 3-line file that says "take this
> XML file and that XSLT file, and display the result". But after over a
> week searching the Internet and even consulting Stack Overflow, I cannot
> find any way of doing this. I literally cannot *believe* that something
> so trivially simple is also so utterly impossible.
>
> If there /is/ a way of doing this, every single XSL tutorial in
> Christendom fails to mention it. No XSL FAQs mention it either - it's
> not even that they say it can't be done, it's that none of them even
> contain a question about this topic. This raises the alarming
> possibility that what I'm trying to do might actually be impossible
> after all. (Which is slightly daft, given that it's the entire point of
> XSL existing in the first place...)
>
> To be clear: It seems to be perfectly possible to apply any XSL to any
> XML if you use an external 3rd-party tool. You just can't do it with a
> *web browser*. You know, those programs that know about XML and XSL and
> are installed on every computer in the world. No, you have to select and
> download a special CLI utility if you want to perform such advanced
> wizardry. *sigh*
>
> My first thought: XSL lets you include one stylesheet inside another, so
> maybe you can include one source document inside... erm, no. No you can't.
>
> It looks like it /might/ be plausible to do something with the XSL
> document() function - but I haven't figured out exactly how yet.
>
> Apparently XML itself has a general include feature called XInclude.
> According to Wikipedia, "Browser support: None". *facepalm* OK, so
> that's really going to help then.
>
> About the closest thing I've found is a website that says that if you
> copy and paste a few miles of convoluted JavaScript code, you can make a
> web page that runs the script which then loads the required XML in the
> background, lots the XSL, applies one to the other, and inserts the
> result into a specific position in the DOM of the current document. In
> particular, it cannot /replace/ the current document, it can only be
> /inserted into/ it. So if your XSL generates an entire XHTML document...
> forget it.
>
> (I presume it goes without saying that the first thing this code snippet
> has to do is test whether it's running on Internet Explorer or a
> standards compliant browser. :-P Some things never change...)
>
> So it looks like I'm going to have to sit down and write a special tool
> to take an XML file and copy it, inserting the correct XSL reference
> into the header. How pathetic...
I coded one up in C# in about 15 minutes. It doesn't take much if your language
of choice already has a library for handling xml/xslt.
I found this post rather interesting as my current project is one big stylesheet
to turn raw xml into a legible report. I've learned just how powerful the
language is. There's a ton you can do with it, and I now wonder why everyone
always moans and groans about how difficult it is to deal with.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/03/2012 20:56, Warp wrote:
> Nothing stops you from using&#xx; codes regardless of the encoding.
Correction: The finite limitations of the human mind stop you using hex
codes. :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> <?xml version="1.0" encoding="ISO-8859-1" ?>
>
> Gaah! No! Use UTF-8! 8859-1 is Western European/United States only!
Tell it to [every piece of Windows software that inspects text files].
All of these programs seem to default to that encoding, not UTF-8.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Fortunately, using the wonders of XSL (specifically, XSLT) you can have
>> the browser transform the raw XML into a pretty-looking XHTML document.
>>
>> But *only* if you edit the original XML file to mention the XSLT file
>> that you want to apply.
>
> I coded one up in C# in about 15 minutes. It doesn't take much if your language
> of choice already has a library for handling xml/xslt.
It only takes 15 /seconds/ to type in a command if you have a 3rd party
external XSLT processor (e.g., Saxon). But apparently you can't get the
/web browser/ to do this. You have to create a new, separate,
transformed version of the file.
It might not sound like much, but it means every time you change the
program that generates the XML, you can't just rerun that program. You
have to rerun the program, and then rerun Saxon (or whatever), and then
reload the browser page. It's a PITA.
What I ended up doing, obviously, was providing a way to change the XSL
reference that the original program inserts into the XML file. :-P
> I found this post rather interesting as my current project is one big stylesheet
> to turn raw xml into a legible report. I've learned just how powerful the
> language is. There's a ton you can do with it, and I now wonder why everyone
> always moans and groans about how difficult it is to deal with.
[I presume you're talking about XSLT here.]
It's interesting that there's one set of facilities for processing the
input functionally, and a separate, redundant set for processing it
imperatively. The latter set is much less powerful to boot. (Perhaps
that was deliberate.)
What I can't figure out is this: How do I make it process an element one
way if it contains a "small" amount of content, and process it a
different way if it contains a "large" amount of content?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On 09/03/2012 20:56, Warp wrote:
>
>> Nothing stops you from using&#xx; codes regardless of the encoding.
>
> Correction: The finite limitations of the human mind stop you using hex
> codes. :-P
step 1: www.google.com
step 2: "unicode chart for _____ characters"
step 3: File | print
step 4: Tape to side of computer screen.
Back when dinosaurs roamed the Earth, that's what most of us did for
DOS-based editors when we needed accented characters, or for the more
daring, ASCII graphics.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> <?xml version="1.0" encoding="ISO-8859-1" ?>
>>
>> Gaah! No! Use UTF-8! 8859-1 is Western European/United States only!
>
> Tell it to [every piece of Windows software that inspects text files].
> All of these programs seem to default to that encoding, not UTF-8.
Change your local settings to Bulgaria or Czech Republic and it won't!
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
