Question about proposing the creation of a new format

Hello everybody,

I'm new in this list. I'm writing here because I have a doubt. Now I'm a not
(very) experienced programmer, but I have many ideas and I'm not sure if
that ideas are good or not. I've thought that maybe the people in this list
can tell me if it's a disaster or not.

Since many time ago I'm frustrated with ebooks formats, specially when I
have to read technic or scientific books. Then i thought "mm, may be there's
a way to improve the reading experience with new (free, as in freedom)
tools".

The idea: (I'm sorry if I don't write very well, I'm spanish and I usually
make mistakes)

The idea is (basically) to design a new format specification (for ebooks)
that allows many interesting properties (or to improve an existing
specification). Ok, that's not a good explanation of that's in my mind, I'll
try to tell point per point.

The actual ebooks haven't many advantages over traditional books: price and
weight (and maybe a little detail more). But the concept of ebook is more
powerful. We can make use of many simple IA algorithms and introduce
semantic data in books to achieve interesting goals...

· Alternative reading flows ( I tell the "reader" that i want to understand
a paragraph, then the reader constructs for me the minimum text that lets me
to understand what I want... obviously, not with magic and not with an
exceptional IA, we can add metadata that stablish depency relations between
paragraphs... for example).
· Indexes created automaticly from the text structure, on the fly, not in
writer time.
· Special tags for special words (or phrases), such as definitions,
theorems, proofs... -> the possibility of create automaticly (in reading
time) tables of many parts of the content (such as an automatic studying
summary or resume). In technic or scientific books could be very
interesting. This lets to separate the narrative of a book of the capable of
being systematized data: definitions, theorems, proofs, formulas, tables,
graphs, figures...
· The capability of sorting data tables by many parameters (growing or
decreasing order, by column, by row..) (with limitations, if the writter
decides to lock the entire table or parts of it, then without that
capability) -> this lets to looks at the data following the way that helps
us more without having to do the work of rmanually rewriting tables.
· Contextual data without context changes: usually, if we want to remember
what means a word, we have to go back in the text, or click an anchor... if
we are lucky, we have tabs, in other cases we have to deal with many windows
or with the "go back" button. A solution could be modyfing the layout in
reading time (i suppose that the ebooks have liquid layout to suit better in
many different devices): If i want to read about a word, and i have the luck
that the word is defined in the same book, a solution could be that a bubble
apears in above the word with the definition written inside. (moving the
text to avoid hiding the closer text). This lets to read the definition
without losing the context in wich we found it, and helping the reader to
understand it.
· Reading profiles: many times, depending on the device what are we using,
it's preferible to use an image or other (because contrast, size,
colors...). In the PC there are no problems, but if "we" want to expand the
usage of the format, it's important to convice the devices industry.
· The capability of "hyperlinking" books by it's identificator (not URL)...
I'm thinking in something like IABN (it's similar to ISBN, but more
"universal", based on SHA256).
· The capability of distinguish between many types of specialized data, such
as formulas, musical scores, source code, flow diagrams, and many others.
· There other ideas but it's hard to me writting it because i'm losing a lot
of nuances on the way.

About the technologies... I've thought in study the ODF format, the EPUB
format, and RDF....

At one point I plan a project, but I'm not so good programmer to do it
alone, and the people who I conviced now are not conviced because they want
to get rich, not to work to achive an interesting goal (interesting for me,
i don't know what the people will think)... in any case, my original idea
was to program with C++ plus Javascript and reuse a lot of code: (webkit to
program the viewer program, http://www.mathjax.org/ for inserting TeX and
MathML, http://steamdev.com/snippet/ for inserting source code,
http://www.vexflow.com/ and http://jtab.tardate.com/ to insert music
scores... )

In any case, I am aware that these are just dreams... but... ¿what do you
think?

Thanks for your atention, Kind regards ^_^

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted

On Sun, Apr 24, 2011 at 6:59 PM, CaStarCo <[hidden email]> wrote:
What you are proposing basically sounds like latex.  But you need to
be careful to separate out the format from the software that reads the
format.  Stuff like sorting tables, choosing layouts, choosing colors,
inserting other text, linking to other resources, that all has to be
handled by the program.  The format just need to provide the right
information to allow the software to do this.

> · Alternative reading flows ( I tell the "reader" that i want to understand
> a paragraph, then the reader constructs for me the minimum text that lets me
> to understand what I want... obviously, not with magic and not with an
> exceptional IA, we can add metadata that stablish depency relations between
> paragraphs... for example).

This requires the text be stored in a manner that makes it easy to
change the flow.  The flow itself would be determined by the software.
 This is the whole point of latex.

> · Indexes created automaticly from the text structure, on the fly, not in
> writer time.
> · Special tags for special words (or phrases), such as definitions,
> theorems, proofs... -> the possibility of create automaticly (in reading
> time) tables of many parts of the content (such as an automatic studying
> summary or resume). In technic or scientific books could be very
> interesting. This lets to separate the narrative of a book of the capable of
> being systematized data: definitions, theorems, proofs, formulas, tables,
> graphs, figures...

These are the same thing.  There would just need to be a tag for "put
this in the index with this label".  I assume latex can do this.

> · The capability of sorting data tables by many parameters (growing or
> decreasing order, by column, by row..) (with limitations, if the writter
> decides to lock the entire table or parts of it, then without that
> capability) -> this lets to looks at the data following the way that helps
> us more without having to do the work of rmanually rewriting tables.

This would be in the software, rather than the format.  The format
would just need to be able to store tables as actual tables, rather
than as text with lines.

This would be in the software, rather than the file format.  The
format would just need to be able to store text and pictures in such a
way that it is easy to change their flow without breaking things.
Latex can do this.

> · Reading profiles: many times, depending on the device what are we using,
> it's preferible to use an image or other (because contrast, size,
> colors...). In the PC there are no problems, but if "we" want to expand the
> usage of the format, it's important to convice the devices industry.

This would be part of the software rather than the file format.  Once
again, the format would need to store text in a way that it is easy to
change basic properties without breaking the layout.  Latex can do
this.

> · The capability of "hyperlinking" books by it's identificator (not URL)...
> I'm thinking in something like IABN (it's similar to ISBN, but more
> "universal", based on SHA256).

This wouldn't be in the format.  The format would could have a way to
store unique identifiers for certain works, but actually looking up
that work would depend on the software.

> · The capability of distinguish between many types of specialized data, such
> as formulas, musical scores, source code, flow diagrams, and many others.

Sounds like latex

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted

On 04/25/2011 08:59 AM, todd rme wrote:

> Sounds like latex

Apart from discussions on the characteristics of the file format, ebooks
are definitely outside the scope of The Document Foundation. There are
already several organizations working around ebooks, and taking care of
the related problems.

--
Italo Vignoli
[hidden email]
mobile +39.348.5653829
VoIP +39.02.320621813
skype italovignoli

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted

2011/4/25 todd rme <[hidden email]>
I know Latex very well, and it's not like LaTeX, I'm talking not about
making layouts automaticly. I'm talking about automatic adaptation to the
user needs in reading time. And, of course, I'm talking to use metadata
inside the format to allow the program to do these actions... I'm not a 16
years old boy, I understand the diferences between the format specification
and what is the viewer work...

I'm talking about making books like* *what we can found in
http://www.touchpress.com/ , but more adaptable, and not closed to an unic
platform like Ipad. The books of touchpress are applications, and I think
that's an error. But, even if making  books as applications is an error, the
idea of dynamism is not an error.

In any case, actually there's not any format capable of adaptation in
reading time (ok, html.. but that needs some javascript, and in general,
it's not self-contained, I'm talking about making "dynamic books" without
the problems of fixed layouts (pdf), without security problems (like pdf).

--
- Per la llibertat del coneixement -
- Per la llibertat de la ment...       -

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted

On Mon, 2011-04-25 at 09:39 +0200, Italo Vignoli wrote:
> On 04/25/2011 08:59 AM, todd rme wrote:
>
> > Sounds like latex
>
> Apart from discussions on the characteristics of the file format, ebooks
> are definitely outside the scope of The Document Foundation.

Hello Italo,

As far as LibreOffice being a display client for ebooks, I would agree
it is not in scope.

However, should LibreOffice have support for producing documents
targeted to eReaders? I don't know maybe, probably.

Thanks

Drew


--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted

2011/4/25 Italo Vignoli <[hidden email]>

Wich organizations? I think that if we have to trust that these
organizations will innovate we are going to wait a very long time. I know
that I am not a guru and not and expert, but I think that this work is not
impossible.. then, why the actual ebooks are that set of static crap? why
it's so difficult to make technic books for ebook readers? the usage of
semantic data is restricted in a very poor set of cases... and the
"standard" format EPUB is very Spartan.

In any case, it's not like LaTeX, I'm talking about making tools that a not
technic user can understand without a great effort. Anb about making a
format more similar to dynamic web pages (html5 + javascript) than to latex
(but without the risk of executing code, the dynamism should be programmed
in the viewer, wich works with the semantic data embedded in the document).

I was writting to the OpenDocument Foundation because i thought it was a
little more than LibreOffice... It's only LibreOffice?

--
- Per la llibertat del coneixement -
- Per la llibertat de la ment...       -

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted

On Mon, 2011-04-25 at 11:17 +0200, CaStarCo wrote:
<snip>

>
> Wich organizations? I think that if we have to trust that these
> organizations will innovate we are going to wait a very long time. I know
> that I am not a guru and not and expert, but I think that this work is not
> impossible.. then, why the actual ebooks are that set of static crap? why
> it's so difficult to make technic books for ebook readers? the usage of
> semantic data is restricted in a very poor set of cases... and the
> "standard" format EPUB is very Spartan.
>

<snip>

> I was writting to the OpenDocument Foundation

Close - but not quite - this is a list for The Document Foundation.

The OpenDocument standard is overseen by a different organization, OASIS
- http://www.oasis-open.org/

>  because i thought it was a
> little more than LibreOffice... It's only LibreOffice?

I hope that it will be eventually.

Thanks

Drew Jensen


--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 25/04/11 7:11 PM, drew wrote:
>
> As far as LibreOffice being a display client for ebooks, I would
> agree it is not in scope.
>
> However, should LibreOffice have support for producing documents
> targeted to eReaders? I don't know maybe, probably.

The writer2epub extension does a reasonably good job of that already,
although I'd follow it up with editing in Sigil and probably final
tweaking in Calibre.


Regards,
Ben

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREKAAYFAk21QgMACgkQNxrFv6BK4xNDTgCfcLCaD1PeeiSxdj8SyNR0Ztzv
NYkAoOqey/aIYGGvNnF+hBa7m4fIIDXh
=Ctnt
-----END PGP SIGNATURE-----

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted

On 25 April 2011 10:40, drew <[hidden email]> wrote:

I think this is a very interesting issue. We are moving from the dominant
technologies that were designed to put information on paper to the dominant
need of presenting information on screens. With the revolution in digital
readers this is only going to increase and then what relevance has document
formats that are primarily designed to target hard copy output? If odf does
not adapt it will become obsolete.

I am constantly irritated by having to download pdfs, .docs and so on when
all I want to do is view the information without cluttering up my download
area with hundreds of files that only ever get glanced at. In most of these
cases simply putting the info in a web page would do and if it really needs
printing, print that page or create a pdf from it. Even if we are not there
yet, most information in the future will never get printed to hard copy and
that is going to be more the case as time goes on. LO and odf have to be
adapt.


--
Ian

Ofqual Accredited IT Qualifications
The Schools ITQ

www.theINGOTs.org +44 (0)1827 305940

You have received this email from the following company: The Learning
Machine Limited, Reg Office, 36 Ashby Road, Tamworth, Staffordshire, B79
8AQ. Reg No: 05560797, Registered in England and Wales.

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted

Hi Ben, *,

On Mon, Apr 25, 2011 at 11:42 AM, Ben McGinnes <[hidden email]> wrote:
There is also http://odt2daisy.sourceforge.net/ - in case your reader
supports the daisy format.

Other than that: what would be a special requirement for eReaders? I
know PDF is suboptimal because it needs to scale to the display
screen. plain text might be boring to read (headings, etc hard to
spot, lack of structural information for navigation), rtf might not be
supported by the reader...

So there probably is no one-size-fits all solution. And it depends on
what the purpose is: personal use (i.e. conversion of random
documents) or dedicated publishing (aim is to write a book and publish
it) and thus how many restrictions you can impose on the
structure/formatting of the document.

ciao
Christian

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted

On 04/25/2011 11:11 AM, drew wrote:

> However, should LibreOffice have support for producing documents
> targeted to eReaders? I don't know maybe, probably.

I am not an expert on ebooks formats, but I know there are a lot of
efforts around the ePub format to become a standard. Unfortunately,
there are too many commercial interests around ebooks today for the
development of a real independent standard.

Anyway, should such a standard be defined and accepted, I would
personally be in favour of supporting it, as documents are becoming more
pervasive than in the past and in the future will be accessed through a
multitude of devices (many of them being mobile).

Best regards, Italo

--
Italo Vignoli
[hidden email]
mobile +39.348.5653829
VoIP +39.02.320621813
skype italovignoli

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted

There is a draft of the EPUB3 specification (
http://idpf.org/news/epub-3-specification-public-draft-released ), I think
that this spec has many problems: the capability of scripting (wich is
potentially harmful), the low emphasis on semantic data (they use metadata,
but specially related to the book structure, not with its content), to
forget the "3d models" type of media (epub3 "only" supports images, video
and sound, but not 3d models wich the user could explore), and the absence
of "profiles" (they talk about fallbacks, but only for scripting, not for
media content). I suppose there are good reasons to choose that spec and not
an extended one... but at that moment, I can imagine which reasons are.

I think that would be interesting to program an ebook editor, to promote the
EPUB use over other privative formats. Many lacks of the EPUB format can be
covered with scripting, but hidding the scripting to the user, doing it
automaticly behind the scene.

If there are interested people, then I'm interested on helping working on
webkit integration.

Kind regards

2011/4/25 Italo Vignoli <[hidden email]>



--
- Per la llibertat del coneixement -
- Per la llibertat de la ment...       -

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted

scripting, not for media content). I suppose there are good reasons to
> choose that spec and not an extended one... but at that moment, I can
> imagine which reasons are.
>
>
>
Sorry, i wanted to say "but at the moment, I CAN'T imagine wich reasons
are.

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 25/04/11 8:53 PM, Christian Lohmaier wrote:
>
> There is also http://odt2daisy.sourceforge.net/ - in case your reader
> supports the daisy format.

I hadn't even heard of DAISY, but it looks very cool so thanks for
pointing me at it.  I just installed the extension and will have a
little play with it at some nebulous point in the future.

> Other than that: what would be a special requirement for eReaders?

I can't speak for anyone else, but as long as an eReader can display
content as it would in a normal book then it's good enough.  If that
book is a novel, then it will usually be pretty easy (e.g. text,
italics, bold, small capitals, subscript, superscript and maybe
footnotes).  If that book is a text book (e.g. a science book) with
charts, formula, pictures, etc.) then more may be required.

> I know PDF is suboptimal because it needs to scale to the display
> screen.

When it comes to books, PDF is only really useful for type-setting a
print book (e.g. the way Lulu uses them for preparing print on demand
books).

> plain text might be boring to read (headings, etc hard to spot, lack
> of structural information for navigation), rtf might not be
> supported by the reader...

Well, I wouldn't opt for either of those formats.

> So there probably is no one-size-fits all solution. And it depends
> on what the purpose is: personal use (i.e. conversion of random
> documents) or dedicated publishing (aim is to write a book and
> publish it) and thus how many restrictions you can impose on the
> structure/formatting of the document.

Exactly.  At this stage most ebook publishers, including
self-publishers, usually need at least two or three formats for each
publication and often more.  Until your post I was considering PDF,
ePub, Kindle (.mobi) and maybe one or two others (.lit and whatever
Sony uses).  Now you can add DAISY to the list too.

It takes a little time to prepare all the relevant formats, but
compared to the process of writing, proofing and editing, not really
all that much.


Regards,
Ben

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREKAAYFAk22TscACgkQNxrFv6BK4xOCPACg2MrNKNR+rHs1sYTFul8PuyN4
dgcAnixKVPC8dMbq/hZt1TB50JebuPpX
=oQTC
-----END PGP SIGNATURE-----

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted

>I think this is a very interesting issue. We are moving from the dominant
>technologies that were designed to put information on paper to the dominant
>need of presenting information on screens. With the revolution in digital
>readers this is only going to increase and then what relevance has document
>formats that are primarily designed to target hard copy output? If odf does
>not adapt it will become obsolete.
>

Seems to suggest that LO should become some sort of html (or any other
electronic format) editor?

>I am constantly irritated by having to download pdfs, .docs and so on when
>all I want to do is view the information without cluttering up my download

May I suggest to use the 'load url' bar to read documents directly on
the web? As for pdf documents, evince can open directly from the url
when activated via the command terminal

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted

On 26 April 2011 22:48, e-letter <[hidden email]> wrote:

Its already a sort of XML editor :-)



>I am constantly irritated by having to download pdfs, .docs and so on when
>all I want to do is view the information without cluttering up my download

 May I suggest to use the 'load url' bar to read documents directly on
> the web? As for pdf documents, evince can open directly from the url
> when activated via the command terminal
>

There are a number of reasons why this is clumsy. Ok, its a work around but
its not an elegant solution. Most people produce most of these documents
simply because they are locked into a desktop applications mentality and
don't think about what the purpose of the document really is. This isn't
going to change over night but we are clearly in a transition from desktop
being king to at least desktop a lot less important. IMHO, LO needs to be
looking several years ahead because we know how long development can take.
.

>
> --
> Unsubscribe instructions: E-mail to [hidden email]
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.documentfoundation.org/www/discuss/
> All messages sent to this list will be publicly archived and cannot be
> deleted
>



--
Ian

Ofqual Accredited IT Qualifications
The Schools ITQ

www.theINGOTs.org +44 (0)1827 305940

You have received this email from the following company: The Learning
Machine Limited, Reg Office, 36 Ashby Road, Tamworth, Staffordshire, B79
8AQ. Reg No: 05560797, Registered in England and Wales.

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted

<snip>

I use LibO for writing, and produce ebooks from the output.

There are many ebook formats, as has already been pointed out by others, the main two being mobi (Kindle) and epub (almost every other e-reader).  I am active in a forum on ebooks, called mobileread.com.  I think I can say that the majority of writers there use one of two methods for creating ebooks.  Either they use a service called Smashwords, which takes MS Word documents and produces about six different kinds of ebooks, including pdf, txt, rtf, which most people don't count as ebook formats.  Or they use a program called Calibre, which has its support forum on mobileread.com, and which takes odt files as its preferred input.  These two methods I would call the professional approach.

On the other hand, someone interested in converting some of their documents to ebook (read epub) format for storage and use on their e-reader can make use of an extension which has been available for some time for OOo.  I can't remember how good this is, since it's a long time since I used it, but I think it produces acceptable quality for what we can call the non-professional approach.

My take on this suggestion is that LibO does what it does well.  Production of epub documents is a marginal requirement, which does not need to be addressed with a built-in function.  Professionals won't use it, and non-professionals are adequately served by the extension I mentioned - I believe there are now several btw.

So the bottom line is that I vote against incorporating epub production into LibO Writer.

Just my 2c

//James
--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted

> My take on this suggestion is that LibO does what it does well.  Production
> of epub documents is a marginal requirement


I'm sure that is what MSFT thought about Windows in relation to cell phones
and tablets ;-)

, which does not need to be addressed with a built-in function.
>  Professionals won't use it, and non-professionals are adequately served by
> the extension I mentioned - I believe there are now several btw.
>

So the bottom line is that I vote against incorporating epub production into
LibO Writer.Just my 2c

I don't think that was a specific proposal at this point, just that the
entire LO proposition could become marginalised by mobile technologies and
e-publishing in a relatively short space of time.


> //James
> --
> Unsubscribe instructions: E-mail to [hidden email]
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.documentfoundation.org/www/discuss/
> All messages sent to this list will be publicly archived and cannot be
> deleted
>
>



--
Ian

Ofqual Accredited IT Qualifications
The Schools ITQ

www.theINGOTs.org +44 (0)1827 305940

You have received this email from the following company: The Learning
Machine Limited, Reg Office, 36 Ashby Road, Tamworth, Staffordshire, B79
8AQ. Reg No: 05560797, Registered in England and Wales.

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted

Dear good gods alive no! :eave the HTML to proper HTML IDE tools like
Eclipse and don't try to be everything in one package.

On 26/04/2011 22:48, e-letter wrote:
--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted

On 27 April 2011 21:42, Mark Preston <[hidden email]> wrote:

> Dear good gods alive no! :eave the HTML to proper HTML IDE tools like
> Eclipse and don't try to be everything in one package.
>

Hm, you mean like don't bother with OOo/LO because there are plenty of text
editors, separate graphics editors and spreadsheets around. (Certainly
Inkscape makes Draw largely unnecessary) Don't bother with TinyMCE/CKEditor
because there is Dreamweaver and FrontPage (or vice versa).

I wasn't actually suggesting any specific action so no need to jump to
conclusions. All I'm saying is that looking at the way things are going, LO
will either change or become irrelevant. How it would change is something
that needs wider strategic thought but I don't see much evidence of this.
OTOH it could all be happening behind the scenes.

As I said, I'm sure Bill Gates said leave those toy phones to Nokia, RIM and
Apple. Google seem to have been smarter. As mobile and web technologies take
over I can see much harder times ahead for anyone dependent on local
dependencies.

On 26/04/2011 22:48, e-letter wrote:
>> I think this is a very interesting issue. We are moving from the dominant
>> technologies that were designed to put information on paper to the
dominant
>> need of presenting information on screens. With the revolution in digital
>> readers this is only going to increase and then what relevance has
document
>> formats that are primarily designed to target hard copy output? If odf
does
>> not adapt it will become obsolete.
>>
>
> Seems to suggest that LO should become some sort of html (or any other
> electronic format) editor?
>
>> I am constantly irritated by having to download pdfs, .docs and so on
when
>> all I want to do is view the information without cluttering up my
download
>
> May I suggest to use the 'load url' bar to read documents directly on
> the web? As for pdf documents, evince can open directly from the url
> when activated via the command terminal
>

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be
deleted

>


--
Ian

Ofqual Accredited IT Qualifications
The Schools ITQ

www.theINGOTs.org +44 (0)1827 305940

You have received this email from the following company: The Learning
Machine Limited, Reg Office, 36 Ashby Road, Tamworth, Staffordshire, B79
8AQ. Reg No: 05560797, Registered in England and Wales.

--
Unsubscribe instructions: E-mail to [hidden email]
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted