Discussion:
(x)HTML-based office suite? (aka suckless word processing solution-2)
Илья Илембитов
2009-10-18 12:56:01 UTC
Permalink
I believe I made some progress with my little research concerning suckless word processing.
Basically, I realised that things get much easier as soon as we realize that there is no need for paper-centric formats.

First, there is no standard here, that is correctly supported by all office suites on all platforms: ODF (as well as OASIS) is not getting any decent popularity any time soon, common MSO formats often lack needed compatibility (even now when I have to bring .doc files created by OpenOffice to be printed on a Windows machine with MSO I get my formatting partially lost).

Second, there are lots of restrictions being imposed by those formats. They all employ the paradigm of paper-centric documents (documents that are created to be printed), whereas lots of documents people create today (I would say, almost the majority) won't ever be printed and are actually intended to be viewed and edited only between computers: be that sharing over the Net/email, passing them on portable media, etc. Thus, one could actually switch from paper-centric paradigm to screen-centric paradigm, which changes the way we think of formatting - e.g. we don't need page numbering, the references, links and TOC appear in a whole different form. Many other changes come here.

For documents that will actually get printed one could probably employ something like LaTeX/lout/troff/etc - and that's the whole different story.

Then I learnt about the fact that Opera employees actually use HTML for all the documents they share within company. Opera is actually interesting due to the Opera Show format, which is an approach to creating presentations using HTML/JavaScript/CSS only + some easy markup. The only drawback (AFAIK) is that Opera Show is supported only by Opera Browser (there should be addons for Firefox, though).

Then there is S5 with a similar approach (and I believe, better compatibility - not sure about IE6, though).

But what about word processing and spreadsheets?

Word processing is easier, since there are lots of lightweight markup languages (MarkDown being the most famous ones) that support all the basic formatting and produce an XHTML output. Here one could see what I called a screen-based approach: when I define the formatting for my text, I actually define the structure of my text, instead of defining the beautifiers (bold/italic/underline) or font sizes manually - the language interpreter does that for me. Besides, lightweight markup languages are nice here, because usually their tags don't get in the way of a spell checker.

Spreadsheets are a bit trickier. I was looking for a lightweight tool to produce plain text files that can be easily converted to HTML. There is SC, which is really nice (only depends on Curses), has VI-like keybindings and produces .sc files. Which are actually just plain text files with a specific formatting, that can later be converted to CSV (and be used in xhtml documents). And I think that it should be pretty easy to convert CSV to any lightweight markup language syntax for tables. The only drawback with SC is that it doesn't have Unicode support (the last update of SC was in 2002, when Unicode wasn't popular enough), so I couldn't get it to work with non-Latin characters. So I am looking for something similar, but more recent. Any ideas here?

Second, tools like SC naturally can't produce graphs. I know there are lots of plot utilities, but I couldn't really find what I needed. What I wanted was a small (C, preferably) console tool (so that I could invoke it right from VIM) that could produce images with graphs (or diagrams) using the provided CSV file. That image can later be used within the resulting xhtml file.

So, basically, to sum up, this way one can get a pretty flexible single document type that can easily mix text elements with tables (produced by a spreadsheet tool like sc) and graphics (be that images or graphs for the provided data in the tables). This document can be later viewed and edited (provided we send the source files as well) on literally any machine with a web browser (including IE6). And of course it can be easily published on the Web.

This way, one can use almost any text editor that can:
-highlight syntax (for MarkDown or any other lightweight language)
-invoke external tools (for conversion of table files, producing graphs and the final conversion to html)
-properly wrap lines and words (which is why nano, being a really nice, easy and tiny editor is not a good solution here)

to replace existing office suites.

What do you think? Can this approach work in real life - for creating academic papers with non-strict formatting, lecture notes, articles - for sharing with your friends, teachers or colleagues that may or may not have any computer skills?

I believe this approach can be easily implemented within Emacs environment (using org-mode and muse-mode, but I would like to implement this idea in VIM (or any other text editor), too - but I need a spreadsheet calculator and a plotter for that. Don't want to cause a flamewar here, of course.
--
wbr, Илембитов
hiro
2009-10-18 13:18:21 UTC
Permalink
wtf is all this spamming about?!
Илья Илембитов
2009-10-18 13:28:35 UTC
Permalink
Well, as far as I can judge, people use this list not only to discuss the existing suckless.org projects (such as dwm, wmii, surf, st, etc) but also to share their ideas about interfaces and productivity that can later be used for future projects. I've seen people discussing desktop publishing and browsers here, so I thought it is appropriate. Actually, there already was a discussion about word processing before (I was the topic starter) and it was OK. So I don't really think my post is off-topic here.
Post by hiro
wtf is all this spamming about?!
--
wbr, Илембитов
Kurt H Maier
2009-10-18 14:41:28 UTC
Permalink
Post by hiro
wtf is all this spamming about?!
He wants to save his spreadsheets in HTML. I wouldn't bother reading it.
--
# Kurt H Maier
Ilya Ilembitov
2009-10-18 14:55:02 UTC
Permalink
Well, spreadsheets weren't the only point. Besides, if we take spreadsheets as a presentation tool (and not as an actual calculation solution, in which case several people should be able to work with the same formulas) - why not? If you are sending a paper where the text is accompanied by some data, who cares for the formulas behind it?
Anyways - what is you suggestion here, then?
Post by hiro
wtf is all this spamming about?!
He wants to save his spreadsheets in HTML. I wouldn't bother reading it.
--
wbr, Ilembitov
Kurt H Maier
2009-10-18 18:35:01 UTC
Permalink
Post by Ilya Ilembitov
if we take spreadsheets as a presentation tool
Why just spreadsheets? Why not /dev/urandom? Or broccoli?
--
# Kurt H Maier
Uriel
2009-10-18 15:36:43 UTC
Permalink
Post by hiro
wtf is all this spamming about?!
He wants to save his spreadsheets in HTML.  I wouldn't bother reading it.
WTF indeed! Is this for real? Its got to be some kind of sick prank or
troll, I can't imagine any other explanation.

I can't conceive any kind of torture painful enough for somebody
proposing we use HTML to store any kind of valuable structured data,
it is off the charts.

uriel
--
# Kurt H Maier
Ilya Ilembitov
2009-10-18 13:35:58 UTC
Permalink
Oops, sorry for those weird symbols. I forgot to check the language in which my name will appear on the list.
Post by Илья Илембитов
I believe I made some progress with my little research concerning suckless word processing.
Basically, I realised that things get much easier as soon as we realize that there is no need for paper-centric formats.
First, there is no standard here, that is correctly supported by all office suites on all platforms: ODF (as well as OASIS) is not getting any decent popularity any time soon, common MSO formats often lack needed compatibility (even now when I have to bring .doc files created by OpenOffice to be printed on a Windows machine with MSO I get my formatting partially lost).
Second, there are lots of restrictions being imposed by those formats. They all employ the paradigm of paper-centric documents (documents that are created to be printed), whereas lots of documents people create today (I would say, almost the majority) won't ever be printed and are actually intended to be viewed and edited only between computers: be that sharing over the Net/email, passing them on portable media, etc. Thus, one could actually switch from paper-centric paradigm to screen-centric paradigm, which changes the way we think of formatting - e.g. we don't need page numbering, the references, links and TOC appear in a whole different form. Many other changes come here.
For documents that will actually get printed one could probably employ something like LaTeX/lout/troff/etc - and that's the whole different story.
Then I learnt about the fact that Opera employees actually use HTML for all the documents they share within company. Opera is actually interesting due to the Opera Show format, which is an approach to creating presentations using HTML/JavaScript/CSS only + some easy markup. The only drawback (AFAIK) is that Opera Show is supported only by Opera Browser (there should be addons for Firefox, though).
Then there is S5 with a similar approach (and I believe, better compatibility - not sure about IE6, though).
But what about word processing and spreadsheets?
Word processing is easier, since there are lots of lightweight markup languages (MarkDown being the most famous ones) that support all the basic formatting and produce an XHTML output. Here one could see what I called a screen-based approach: when I define the formatting for my text, I actually define the structure of my text, instead of defining the beautifiers (bold/italic/underline) or font sizes manually - the language interpreter does that for me. Besides, lightweight markup languages are nice here, because usually their tags don't get in the way of a spell checker.
Spreadsheets are a bit trickier. I was looking for a lightweight tool to produce plain text files that can be easily converted to HTML. There is SC, which is really nice (only depends on Curses), has VI-like keybindings and produces .sc files. Which are actually just plain text files with a specific formatting, that can later be converted to CSV (and be used in xhtml documents). And I think that it should be pretty easy to convert CSV to any lightweight markup language syntax for tables. The only drawback with SC is that it doesn't have Unicode support (the last update of SC was in 2002, when Unicode wasn't popular enough), so I couldn't get it to work with non-Latin characters. So I am looking for something similar, but more recent. Any ideas here?
Second, tools like SC naturally can't produce graphs. I know there are lots of plot utilities, but I couldn't really find what I needed. What I wanted was a small (C, preferably) console tool (so that I could invoke it right from VIM) that could produce images with graphs (or diagrams) using the provided CSV file. That image can later be used within the resulting xhtml file.
So, basically, to sum up, this way one can get a pretty flexible single document type that can easily mix text elements with tables (produced by a spreadsheet tool like sc) and graphics (be that images or graphs for the provided data in the tables). This document can be later viewed and edited (provided we send the source files as well) on literally any machine with a web browser (including IE6). And of course it can be easily published on the Web.
-highlight syntax (for MarkDown or any other lightweight language)
-invoke external tools (for conversion of table files, producing graphs and the final conversion to html)
-properly wrap lines and words (which is why nano, being a really nice, easy and tiny editor is not a good solution here)
to replace existing office suites.
What do you think? Can this approach work in real life - for creating academic papers with non-strict formatting, lecture notes, articles - for sharing with your friends, teachers or colleagues that may or may not have any computer skills?
I believe this approach can be easily implemented within Emacs environment (using org-mode and muse-mode, but I would like to implement this idea in VIM (or any other text editor), too - but I need a spreadsheet calculator and a plotter for that. Don't want to cause a flamewar here, of course.
--
wbr, Ilembitov
Antoni Grzymala
2009-10-18 14:29:48 UTC
Permalink
Post by Ilya Ilembitov
Oops, sorry for those weird symbols. I forgot to check the language in
which my name will appear on the list.
UTF-8 is not prohibited on this list. The symbols were perfectly fine,
thank you very much :).
--
[a]
Ilya Ilembitov
2009-10-18 14:51:41 UTC
Permalink
Oh, ok. It's just I've checked http://lists.suckless.org/dev/0910/index.html - that's why I was alarmed.
Post by Antoni Grzymala
Post by Ilya Ilembitov
Oops, sorry for those weird symbols. I forgot to check the language in
which my name will appear on the list.
UTF-8 is not prohibited on this list. The symbols were perfectly fine,
thank you very much :).
--
wbr, Ilembitov
Szabolcs Nagy
2009-10-18 15:10:26 UTC
Permalink
Post by Ilya Ilembitov
Oh, ok. It's just I've checked http://lists.suckless.org/dev/0910/index.html
- that's why I was alarmed.
Post by Antoni Grzymala
Post by Ilya Ilembitov
Oops, sorry for those weird symbols. I forgot to check the language in
which my name will appear on the list.
UTF-8 is not prohibited on this list. The symbols were perfectly fine,
it was koi8-r, not utf8
Uriel
2009-10-18 15:38:00 UTC
Permalink
Post by Szabolcs Nagy
Post by Ilya Ilembitov
Oh, ok. It's just I've checked http://lists.suckless.org/dev/0910/index.html
- that's why I was alarmed.
Post by Antoni Grzymala
Post by Ilya Ilembitov
Oops, sorry for those weird symbols. I forgot to check the language in
which my name will appear on the list.
UTF-8 is not prohibited on this list. The symbols were perfectly fine,
it was koi8-r, not utf8
Then somebody needs to be burned at the stake. In this day and age,
anyone using *any* encoding other than UTF-8 need to be lockedup and
have the key thrown into a black hole, enough harm has been done
already by retarded encodings.

uriel
Antoni Grzymala
2009-10-18 15:51:56 UTC
Permalink
Post by Uriel
Post by Szabolcs Nagy
Post by Ilya Ilembitov
Oh, ok. It's just I've checked http://lists.suckless.org/dev/0910/index.html
- that's why I was alarmed.
Post by Antoni Grzymala
Post by Ilya Ilembitov
Oops, sorry for those weird symbols. I forgot to check the language in
which my name will appear on the list.
UTF-8 is not prohibited on this list. The symbols were perfectly fine,
it was koi8-r, not utf8
Then somebody needs to be burned at the stake. In this day and age,
anyone using *any* encoding other than UTF-8 need to be lockedup and
have the key thrown into a black hole, enough harm has been done
already by retarded encodings.
I thought that was UTF-8, cause it was read fine by my MUA. Thank you,
mutt.
--
[a]
Kurt H Maier
2009-10-18 18:36:48 UTC
Permalink
Post by Uriel
In this day and age,
anyone using *any* encoding other than UTF-8 need to be lockedup and
have the key thrown into a black hole, enough harm has been done
already by retarded encodings.
ASCII works just fine, thanks. I have yet to see a UTF-8
implementation that was anything but utterly broken. I've heard plan
9's implementation is okay, but there's no way I'm wading through plan
9's retarded mouse-based interface just for a character encoding.
--
# Kurt H Maier
Antoni Grzymala
2009-10-18 18:48:45 UTC
Permalink
Post by Kurt H Maier
In this day and age, anyone using *any* encoding other than UTF-8
need to be lockedup and have the key thrown into a black hole,
enough harm has been done already by retarded encodings.
ASCII works just fine, thanks.
Just fine for the Americans?
Post by Kurt H Maier
I have yet to see a UTF-8 implementation that was anything but utterly
broken.
Most I'm dealing with do what they are supposed to (ie. work).
--
[a]
Szabolcs Nagy
2009-10-18 19:15:31 UTC
Permalink
Post by Antoni Grzymala
Post by Kurt H Maier
ASCII works just fine, thanks.
Just fine for the Americans?
fine for anyone who is willing to communicate in english
Antoni Grzymala
2009-10-18 19:26:00 UTC
Permalink
Post by Szabolcs Nagy
Post by Antoni Grzymala
Post by Kurt H Maier
ASCII works just fine, thanks.
Just fine for the Americans?
fine for anyone who is willing to communicate in english
Yes, let's ditch our national languages, spelling and diacritics, just
because a minority of users of a niche mailing list bitch about some
apparently failed UTF-8 implementations.

Heh... Especially related to the topic of the thread. From today on you
will only communicate with your Hungarian colleagues using ASCII. Best
of luck.
--
[a]
Kurt H Maier
2009-10-18 19:31:31 UTC
Permalink
Post by Antoni Grzymala
Yes, let's ditch our national languages, spelling and diacritics, just
because a minority of users of a niche mailing list bitch about some
apparently failed UTF-8 implementations.
You don't have to ditch anything. You'll just be less disappointed if
you don't expect everyone to care.
Post by Antoni Grzymala
Heh... Especially related to the topic of the thread. From today on you
will only communicate with your Hungarian colleagues using ASCII. Best
of luck.
I communicate with people all over the world, and ASCII seems to do
the trick. Where's the impetus to change, again?
--
# Kurt H Maier
Antoni Grzymala
2009-10-18 19:50:33 UTC
Permalink
Post by Kurt H Maier
Post by Antoni Grzymala
Heh... Especially related to the topic of the thread. From today on you
will only communicate with your Hungarian colleagues using ASCII. Best
of luck.
I communicate with people all over the world, and ASCII seems to do
the trick. Where's the impetus to change, again?
In Hungarian? Otherwise, stop trolling now, please.
--
[a]
Kurt H Maier
2009-10-18 21:56:03 UTC
Permalink
Post by Antoni Grzymala
Post by Kurt H Maier
I communicate with people all over the world, and ASCII seems to do
the trick.  Where's the impetus to change, again?
In Hungarian? Otherwise, stop trolling now, please.
Aww come on I'm just getting started. Wait'll you hear about how I
scan in handwriting and convert the .png with libcaca!
--
# Kurt H Maier
Moritz Wilhelmy
2009-10-18 21:58:05 UTC
Permalink
Post by Kurt H Maier
Post by Antoni Grzymala
Post by Kurt H Maier
I communicate with people all over the world, and ASCII seems to do
the trick.  Where's the impetus to change, again?
In Hungarian? Otherwise, stop trolling now, please.
Aww come on I'm just getting started. Wait'll you hear about how I
scan in handwriting and convert the .png with libcaca!
--
# Kurt H Maier
You are a hero.
Would both of you please stop this discussion now? thanks.

Regards
Antoni Grzymala
2009-10-18 22:02:24 UTC
Permalink
Post by Kurt H Maier
Post by Antoni Grzymala
Post by Kurt H Maier
I communicate with people all over the world, and ASCII seems to do
the trick.  Where's the impetus to change, again?
In Hungarian? Otherwise, stop trolling now, please.
Aww come on I'm just getting started. Wait'll you hear about how I
scan in handwriting and convert the .png with libcaca!
Haha ;)
--
[a]
Uriel
2009-10-19 14:24:30 UTC
Permalink
Post by Szabolcs Nagy
Post by Antoni Grzymala
Post by Kurt H Maier
ASCII works just fine, thanks.
Just fine for the Americans?
fine for anyone who is willing to communicate in english
People unwilling to communicating in English are not worth communicating with.

uriel
pancake
2009-10-19 14:29:04 UTC
Permalink
How can you spend that much time talking about shit?

I wonder how many people can make the world better with all your spare
time (R).
Post by Uriel
Post by Szabolcs Nagy
Post by Antoni Grzymala
Post by Kurt H Maier
ASCII works just fine, thanks.
Just fine for the Americans?
fine for anyone who is willing to communicate in english
People unwilling to communicating in English are not worth communicating with.
uriel
Antoni Grzymala
2009-10-19 14:49:04 UTC
Permalink
Post by Uriel
Post by Szabolcs Nagy
Post by Antoni Grzymala
Post by Kurt H Maier
ASCII works just fine, thanks.
Just fine for the Americans?
fine for anyone who is willing to communicate in english
People unwilling to communicating in English are not worth communicating with.
I'd say “unwilling to communicate” would be more in English, but let's
leave that aside.

Are you proposing that nationals of a single non-English nationality
(which was the topic of the main thread among other things) should
communicate between themselves in English because there's the God-send
called ASCII and Uriel says so?

These threads grow to such let's-see-how-far-beyond-trolling-we-can-go
monstrosities that I can't believe my eyes sometimes. On the other hand,
sometimes it's just plain hilarious.
--
[a]
Kurt H Maier
2009-10-19 15:13:41 UTC
Permalink
Post by Antoni Grzymala
Are you proposing that nationals of a single non-English nationality
(which was the topic of the main thread among other things) should
communicate between themselves in English because there's the God-send
called ASCII and Uriel says so?
No, Uriel likes UTF-8 for English. That way your charset can support
all of the localized alphabets you won't be using.
--
# Kurt H Maier
Kris Maglione
2009-10-21 00:32:14 UTC
Permalink
Post by Kurt H Maier
Post by Antoni Grzymala
Are you proposing that nationals of a single non-English nationality
(which was the topic of the main thread among other things) should
communicate between themselves in English because there's the God-send
called ASCII and Uriel says so?
No, Uriel likes UTF-8 for English. That way your charset can support
all of the localized alphabets you won't be using.
It can, all with no added bloat so long as you stay within the
7-bit ASCII range. Then you also get all of the latin and
germanic diacritics which turn out to be useful in a lot of odd
circumstances that come up when you don't expect. You also get
all kinds of math and scientific symbols which are useful to a
lot of people, and which is very painful to those people when
they need to communicate in some eccentric, scientific character
encoding. And people can post their names, or key words, in
their home tongues (or alphabets, or ideographs) without having
to worry that the recipient has their specific national
encoding. Plus, when you agree on a universal encoding, you
don't have to worry about which encoding a file you've received
is in. Whether it's 8859-1, 8859-4, windows-1250, Shift-JIS,
UCS-2, UCS-4, or whatever.
--
Kris Maglione

When a religion is good, I conceive it will support itself; and when
it does not support itself, and God does not take care to support it
so that its professors are obliged to call for help of the civil
power, 'tis a sign, I apprehend, of its being a bad one.
--Benjamin Franklin
Anselm R Garbe
2009-10-18 15:43:44 UTC
Permalink
Post by Илья Илембитов
I believe I made some progress with my little research concerning suckless word processing.
Basically, I realised that things get much easier as soon as we realize that there is no need for paper-centric formats.
First, there is no standard here, that is correctly supported by all office suites on all platforms: ODF (as well as OASIS) is not getting any decent popularity any time soon, common MSO formats often lack needed compatibility (even now when I have to bring .doc files created by OpenOffice to be printed on a Windows machine with MSO I get my formatting partially lost).
Second, there are lots of restrictions being imposed by those formats. They all employ the paradigm of paper-centric documents (documents that are created to be printed), whereas lots of documents people create today (I would say, almost the majority) won't ever be printed and are actually intended to be viewed and edited only between computers: be that sharing over the Net/email, passing them on portable media, etc. Thus, one could actually switch from paper-centric paradigm to screen-centric paradigm, which changes the way we think of formatting - e.g. we don't need page numbering, the references, links and TOC appear in a whole different form. Many other changes come here.
For documents that will actually get printed one could probably employ something like LaTeX/lout/troff/etc - and that's the whole different story.
Then I learnt about the fact that Opera employees actually use HTML for all the documents they share within company. Opera is actually interesting due to the Opera Show format, which is an approach to creating presentations using HTML/JavaScript/CSS only + some easy markup. The only drawback (AFAIK) is that Opera Show is supported only by Opera Browser (there should be addons for Firefox, though).
Then there is S5 with a similar approach (and I believe, better compatibility - not sure about IE6, though).
But what about word processing and spreadsheets?
Word processing is easier, since there are lots of lightweight markup languages (MarkDown being the most famous ones) that support all the basic formatting and produce an XHTML output. Here one could see what I called a screen-based approach: when I define the formatting for my text, I actually define the structure of my text, instead of defining the beautifiers (bold/italic/underline) or font sizes manually - the language interpreter does that for me. Besides, lightweight markup languages are nice here, because usually their tags don't get in the way of a spell checker.
Spreadsheets are a bit trickier. I was looking for a lightweight tool to produce plain text files that can be easily converted to HTML. There is SC, which is really nice (only depends on Curses), has VI-like keybindings and produces .sc files. Which are actually just plain text files with a specific formatting, that can later be converted to CSV (and be used in xhtml documents). And I think that it should be pretty easy to convert CSV to any lightweight markup language syntax for tables. The only drawback with SC is that it doesn't have Unicode support (the last update of SC was in 2002, when Unicode wasn't popular enough), so I couldn't get it to work with non-Latin characters. So I am looking for something similar, but more recent. Any ideas here?
Second, tools like SC naturally can't produce graphs. I know there are lots of plot utilities, but I couldn't really find what I needed. What I wanted was a small (C, preferably) console tool (so that I could invoke it right from VIM) that could produce images with graphs (or diagrams) using the provided CSV file. That image can later be used within the resulting xhtml file.
So, basically, to sum up, this way one can get a pretty flexible single document type that can easily mix text elements with tables (produced by a spreadsheet tool like sc) and graphics (be that images or graphs for the provided data in the tables). This document can be later viewed and edited (provided we send the source files as well) on literally any machine with a web browser (including IE6). And of course it can be easily published on the Web.
-highlight syntax (for MarkDown or any other lightweight language)
-invoke external tools (for conversion of table files, producing graphs and the final conversion to html)
-properly wrap lines and words (which is why nano, being a really nice, easy and tiny editor is not a good solution here)
to replace existing office suites.
What do you think? Can this approach work in real life - for creating academic papers with non-strict formatting, lecture notes, articles - for sharing with your friends, teachers or colleagues that may or may not have any computer skills?
I believe this approach can be easily implemented within Emacs environment (using org-mode and muse-mode, but I would like to implement this idea in VIM (or any other text editor), too - but I need a spreadsheet calculator and a plotter for that. Don't want to cause a flamewar here, of course.
So reading your mail can be summarised as a 2x2 matrix:

WPS WPP
SPS SPP

WPS means word processor screen presentation, WPP means word processor
print presentation, SPS means spreadsheet screen representation, SPP
means spreadsheet print presentation.

Ok, as far as I understand what you are proposing is WPP and SPP are
mostly not interesting and can be avoided in 90% of all cases.

For WPS and SPS you come up with HTML as the presentation format +
some source tools right?
I mean that can work, but is not any better as using propietary formats.

To sum up my view: I think there is a lack of decent WYSIWYG word
processors (for both, screen and paper presentation), but MS
Word/Powerpoint is still the leader in this area, and there is a lack
of usable spreadsheet processors (again MS Excel is the best one can
get).

I agree there should be good replacements, but I don't expect them to
appear in the OSS world very soon, and I pretty much doubt we at
suckless can produce something good in the short term.

Though I'm open minded to see what people use and why they think
that's good. Your proposals however are just HTML imho, and I'm not
very convinced about that, not because I think HTML sucks, but because
HTML is a moving target and never settles and will never settle, and
your documents will look totally different every once in a while (esp
if you enrich it with CSS and JS).

Kind regards,
Anselm
Ilya Ilembitov
2009-10-18 15:49:48 UTC
Permalink
Yes, you got it totally right. But why do you believe that html would be on par with proprietary formats? I mean, is there any possibility that html produced by markdown (or similar languages) interpreter won't be displayed correctly in most of browsers (including IE)? I thought it's basic and standartized enough. I do agree, though, that S5 is likely to have some issues.
Post by Илья Илембитов
I believe I made some progress with my little research concerning suckless word processing.
Basically, I realised that things get much easier as soon as we realize that there is no need for paper-centric formats.
First, there is no standard here, that is correctly supported by all office suites on all platforms: ODF (as well as OASIS) is not getting any decent popularity any time soon, common MSO formats often lack needed compatibility (even now when I have to bring .doc files created by OpenOffice to be printed on a Windows machine with MSO I get my formatting partially lost).
Second, there are lots of restrictions being imposed by those formats. They all employ the paradigm of paper-centric documents (documents that are created to be printed), whereas lots of documents people create today (I would say, almost the majority) won't ever be printed and are actually intended to be viewed and edited only between computers: be that sharing over the Net/email, passing them on portable media, etc. Thus, one could actually switch from paper-centric paradigm to screen-centric paradigm, which changes the way we think of formatting - e.g. we don't need page numbering, the references, links and TOC appear in a whole different form. Many other changes come here.
For documents that will actually get printed one could probably employ something like LaTeX/lout/troff/etc - and that's the whole different story.
Then I learnt about the fact that Opera employees actually use HTML for all the documents they share within company. Opera is actually interesting due to the Opera Show format, which is an approach to creating presentations using HTML/JavaScript/CSS only + some easy markup. The only drawback (AFAIK) is that Opera Show is supported only by Opera Browser (there should be addons for Firefox, though).
Then there is S5 with a similar approach (and I believe, better compatibility - not sure about IE6, though).
But what about word processing and spreadsheets?
Word processing is easier, since there are lots of lightweight markup languages (MarkDown being the most famous ones) that support all the basic formatting and produce an XHTML output. Here one could see what I called a screen-based approach: when I define the formatting for my text, I actually define the structure of my text, instead of defining the beautifiers (bold/italic/underline) or font sizes manually - the language interpreter does that for me. Besides, lightweight markup languages are nice here, because usually their tags don't get in the way of a spell checker.
Spreadsheets are a bit trickier. I was looking for a lightweight tool to produce plain text files that can be easily converted to HTML. There is SC, which is really nice (only depends on Curses), has VI-like keybindings and produces .sc files. Which are actually just plain text files with a specific formatting, that can later be converted to CSV (and be used in xhtml documents). And I think that it should be pretty easy to convert CSV to any lightweight markup language syntax for tables. The only drawback with SC is that it doesn't have Unicode support (the last update of SC was in 2002, when Unicode wasn't popular enough), so I couldn't get it to work with non-Latin characters. So I am looking for something similar, but more recent. Any ideas here?
Second, tools like SC naturally can't produce graphs. I know there are lots of plot utilities, but I couldn't really find what I needed. What I wanted was a small (C, preferably) console tool (so that I could invoke it right from VIM) that could produce images with graphs (or diagrams) using the provided CSV file. That image can later be used within the resulting xhtml file.
So, basically, to sum up, this way one can get a pretty flexible single document type that can easily mix text elements with tables (produced by a spreadsheet tool like sc) and graphics (be that images or graphs for the provided data in the tables). This document can be later viewed and edited (provided we send the source files as well) on literally any machine with a web browser (including IE6). And of course it can be easily published on the Web.
-highlight syntax (for MarkDown or any other lightweight language)
-invoke external tools (for conversion of table files, producing graphs and the final conversion to html)
-properly wrap lines and words (which is why nano, being a really nice, easy and tiny editor is not a good solution here)
to replace existing office suites.
What do you think? Can this approach work in real life - for creating academic papers with non-strict formatting, lecture notes, articles - for sharing with your friends, teachers or colleagues that may or may not have any computer skills?
I believe this approach can be easily implemented within Emacs environment (using org-mode and muse-mode, but I would like to implement this idea in VIM (or any other text editor), too - but I need a spreadsheet calculator and a plotter for that. Don't want to cause a flamewar here, of course.
WPS WPP
SPS SPP
WPS means word processor screen presentation, WPP means word processor
print presentation, SPS means spreadsheet screen representation, SPP
means spreadsheet print presentation.
Ok, as far as I understand what you are proposing is WPP and SPP are
mostly not interesting and can be avoided in 90% of all cases.
For WPS and SPS you come up with HTML as the presentation format +
some source tools right?
I mean that can work, but is not any better as using propietary formats.
To sum up my view: I think there is a lack of decent WYSIWYG word
processors (for both, screen and paper presentation), but MS
Word/Powerpoint is still the leader in this area, and there is a lack
of usable spreadsheet processors (again MS Excel is the best one can
get).
I agree there should be good replacements, but I don't expect them to
appear in the OSS world very soon, and I pretty much doubt we at
suckless can produce something good in the short term.
Though I'm open minded to see what people use and why they think
that's good. Your proposals however are just HTML imho, and I'm not
very convinced about that, not because I think HTML sucks, but because
HTML is a moving target and never settles and will never settle, and
your documents will look totally different every once in a while (esp
if you enrich it with CSS and JS).
Kind regards,
Anselm
--
wbr, Ilembitov
Anselm R Garbe
2009-10-18 16:20:49 UTC
Permalink
Post by Ilya Ilembitov
Yes, you got it totally right. But why do you believe that html would be on par with proprietary formats? I mean, is there any possibility that html produced by markdown (or similar languages) interpreter won't be displayed correctly in most of browsers (including IE)? I thought it's basic and standartized enough. I do agree, though, that S5 is likely to have some issues.
The problem with HTML is that it's vagely defined and that it looks
different not only in every browser but also every 2 years (because
some mastermind came up with the next CSS and DOM features).

This doesn't happen with plain text, so if you ask me what's better:
HTML or Markdown, my answer should be clear. Plain text will look the
same in 100 years, but potentially there won't be any HTML4 or HTML5
browser around in 25 years time...

(as a side-note: If you use troff or TeX I bet you will get proper
results in a hundred years time as well).

Of course the sustainability argument isn't very important if it's
just about a presentation of the next great future technology that
will be obsolete in 5 years anyways. For such I recommend use HTML,
they will be a relict of their time anyways by then ;)

Kind regards,
Anselm
Tor Aqissiaq
2009-10-18 17:15:34 UTC
Permalink
XHTML, parsed using an XML parser is very specifically defined and
does not look different in different browsers, but few people serve
XHTML documents with the application/xhtml+xml headers, because IE
refuses to parse XML. XHTML parsed as HTML + no better than HTML. I
already use XHTML for sending documents to my friends.
Post by Anselm R Garbe
Post by Ilya Ilembitov
Yes, you got it totally right. But why do you believe that html would be on par with proprietary formats? I mean, is there any possibility that html produced by markdown (or similar languages) interpreter won't be displayed correctly in most of browsers (including IE)? I thought it's basic and standartized enough. I do agree, though, that S5 is likely to have some issues.
The problem with HTML is that it's vagely defined and that it looks
different not only in every browser but also every 2 years (because
some mastermind came up with the next CSS and DOM features).
HTML or Markdown, my answer should be clear. Plain text will look the
same in 100 years, but potentially there won't be any HTML4 or HTML5
browser around in 25 years time...
(as a side-note: If you use troff or TeX I bet you will get proper
results in a hundred years time as well).
Of course the sustainability argument isn't very important if it's
just about a presentation of the next great future technology that
will be obsolete in 5 years anyways. For such I recommend use HTML,
they will be a relict of their time anyways by then ;)
Kind regards,
Anselm
Szabolcs Nagy
2009-10-18 17:26:00 UTC
Permalink
Post by Tor Aqissiaq
XHTML, parsed using an XML parser is very specifically defined and
does not look different in different browsers,
yeah especially the <script> and <style> elements..
Tor Aqissiaq
2009-10-18 17:38:32 UTC
Permalink
Styles are well defined, and the only web browser I know of that has
ever had problems then is IE. Scripts are not relevent in a word
processing context.
Post by Szabolcs Nagy
Post by Tor Aqissiaq
XHTML, parsed using an XML parser is very specifically defined and
does not look different in different browsers,
yeah especially the <script> and <style> elements..
Anselm R Garbe
2009-10-18 17:35:16 UTC
Permalink
Post by Tor Aqissiaq
XHTML, parsed using an XML parser is very specifically defined and
does not look different in different browsers, but few people serve
XHTML documents with the application/xhtml+xml headers, because IE
refuses to parse XML. XHTML parsed as HTML + no better than HTML. I
already use XHTML for sending documents to my friends.
XHTML is a sick child that will die soon.

Kind regards,
Anselm
Tor Aqissiaq
2009-10-18 17:39:47 UTC
Permalink
What is wrong with XHTML? Are you implying that HTML is superior?
Post by Anselm R Garbe
Post by Tor Aqissiaq
XHTML, parsed using an XML parser is very specifically defined and
does not look different in different browsers, but few people serve
XHTML documents with the application/xhtml+xml headers, because IE
refuses to parse XML. XHTML parsed as HTML + no better than HTML. I
already use XHTML for sending documents to my friends.
XHTML is a sick child that will die soon.
Kind regards,
Anselm
Anselm R Garbe
2009-10-18 17:44:34 UTC
Permalink
Post by Tor Aqissiaq
What is wrong with XHTML? Are you implying that HTML is superior?
Only geeks bother to adopt it. XHTML adoption is around 0.1% of all
web pages, and it is unlikely to take over the world. All browsers and
the web trend travel towards HTML5 for quite some time, there is
really no space left for XHTML...

Kind regards,
Anselm
Tor Aqissiaq
2009-10-18 17:50:36 UTC
Permalink
The only reason XHTML did not replace HTML is because IE did not and
does not support it. It is no more geekier than HTML.

But whether XHTML was or will be adopted by the internet is irrelevent
to this discussion as it regards using XHTML for word processing.
Post by Anselm R Garbe
Post by Tor Aqissiaq
What is wrong with XHTML? Are you implying that HTML is superior?
Only geeks bother to adopt it. XHTML adoption is around 0.1% of all
web pages, and it is unlikely to take over the world. All browsers and
the web trend travel towards HTML5 for quite some time, there is
really no space left for XHTML...
Kind regards,
Anselm
Uriel
2009-10-19 14:22:52 UTC
Permalink
On Sun, Oct 18, 2009 at 7:50 PM, Tor Aqissiaq
Post by Tor Aqissiaq
The only reason XHTML did not replace HTML is because IE did not and
does not support it. It is no more geekier than HTML.
Wrong, even on Firefox, Opera, and WebKit XHTML is badly broken and is
*slower* to parse than HTML. (Plus it breaks any site that depends on
document.write() which is an abomination in itself, but used almost
everywhere).
Post by Tor Aqissiaq
But whether XHTML was or will be adopted by the internet is irrelevent
to this discussion as it regards using XHTML for word processing.
Any discussion of using XHTML for word processing is irrelevant to any
person that is not suffering from bovine spongiform encephalopathy

uriel
Post by Tor Aqissiaq
Post by Anselm R Garbe
Post by Tor Aqissiaq
What is wrong with XHTML? Are you implying that HTML is superior?
Only geeks bother to adopt it. XHTML adoption is around 0.1% of all
web pages, and it is unlikely to take over the world. All browsers and
the web trend travel towards HTML5 for quite some time, there is
really no space left for XHTML...
Kind regards,
Anselm
Uriel
2009-10-19 14:19:19 UTC
Permalink
On Sun, Oct 18, 2009 at 7:39 PM, Tor Aqissiaq
Post by Tor Aqissiaq
What is wrong with XHTML? Are you implying that HTML is superior?
Yes, HTML is superior to XHTML, I was wrong about this one for years,
but now it is completely clear to me that XML is *always* the wrong
answer, and XHTML is what proved it, even something as bad as HTML
becomes worse when one adds XML.

As I said in another post, loading XHTML documents is *slower* than
loading HTML!

XHTML only has one good thing about it: the abomination that is
document.write() doesn't work in XHTML! Of course this actually
contributed to its failure, which is a good thing too.

uriel
Post by Tor Aqissiaq
Post by Anselm R Garbe
Post by Tor Aqissiaq
XHTML, parsed using an XML parser is very specifically defined and
does not look different in different browsers, but few people serve
XHTML documents with the application/xhtml+xml headers, because IE
refuses to parse XML. XHTML parsed as HTML + no better than HTML. I
already use XHTML for sending documents to my friends.
XHTML is a sick child that will die soon.
Kind regards,
Anselm
markus schnalke
2009-10-18 18:21:13 UTC
Permalink
Post by Anselm R Garbe
Post by Tor Aqissiaq
XHTML, parsed using an XML parser is very specifically defined and
does not look different in different browsers, but few people serve
XHTML documents with the application/xhtml+xml headers, because IE
refuses to parse XML. XHTML parsed as HTML + no better than HTML. I
already use XHTML for sending documents to my friends.
XHTML is a sick child that will die soon.
Should and will are a big difference. Don't forget the ``bad real
world'' in your prediction.

Bad stuff often lives long, especially when many people don't see that
it's bad.


meillo
Uriel
2009-10-19 14:15:21 UTC
Permalink
Post by Anselm R Garbe
Post by Tor Aqissiaq
XHTML, parsed using an XML parser is very specifically defined and
does not look different in different browsers, but few people serve
XHTML documents with the application/xhtml+xml headers, because IE
refuses to parse XML. XHTML parsed as HTML + no better than HTML. I
already use XHTML for sending documents to my friends.
XHTML is a sick child that will die soon.
And when it dies we can party to celebrate one more nail in the coffin of XML.

Good riddance!

uriel
Post by Anselm R Garbe
Kind regards,
Anselm
Uriel
2009-10-19 14:11:53 UTC
Permalink
XHTML is failure, and has been pretty much abandoned even by the web
2.0 people. Believe it or not, XHTML is still seriously crippled when
compared to HTML, and even the XHTML validator can't use it!

Also turns out most browsers render XHTML much more slowly than HTML,
because parsing XHTML is *HARDER* (yes, I was also stupid enough to
buy the myth that parsing XHTML would be faster, well, seems XML sucks
even more than I though!).

That XHTML is dying is a very good thing, it is another nail in the
coffin of XML, which is probably the most dangerous disease to afflict
the software industry in some time.

uriel

P.S.: I recently converted werc from XHTML to HTML5, and it was clear
improvement, much less verbose crap, much more clear and concise
markup.

On Sun, Oct 18, 2009 at 7:15 PM, Tor Aqissiaq
Post by Tor Aqissiaq
XHTML, parsed using an XML parser is very specifically defined and
does not look different in different browsers, but few people serve
XHTML documents with the application/xhtml+xml headers, because IE
refuses to parse XML. XHTML parsed as HTML + no better than HTML. I
already use XHTML for sending documents to my friends.
Post by Anselm R Garbe
Post by Ilya Ilembitov
Yes, you got it totally right. But why do you believe that html would be on par with proprietary formats? I mean, is there any possibility that html produced by markdown (or similar languages) interpreter won't be displayed correctly in most of browsers (including IE)? I thought it's basic and standartized enough. I do agree, though, that S5 is likely to have some issues.
The problem with HTML is that it's vagely defined and that it looks
different not only in every browser but also every 2 years (because
some mastermind came up with the next CSS and DOM features).
HTML or Markdown, my answer should be clear. Plain text will look the
same in 100 years, but potentially there won't be any HTML4 or HTML5
browser around in 25 years time...
(as a side-note: If you use troff or TeX I bet you will get proper
results in a hundred years time as well).
Of course the sustainability argument isn't very important if it's
just about a presentation of the next great future technology that
will be obsolete in 5 years anyways. For such I recommend use HTML,
they will be a relict of their time anyways by then ;)
Kind regards,
Anselm
Loading...