No subject
Mon May 5 06:29:14 EDT 2008
understand it, Write is derived from AbiWord and even full native AbiWord
doesn't support .odt import/export without additional plug-ins.
For reference see:
http://www.abisource.com/wiki/OpenDocument_support
and mailing list post referenced within
I'm not inclined to spend any more time on trying to sort this out as .odt
is not a file type that I routinely encounter, and I see no reason to spend
time on it when adequate alternatives exist for my purpose and it works
beautifully on the XO as deployed. I was hard-pressed to even find an
example .odt file to test, as most ODF websites doesn't use .odt very much,
the pages themselves are of course in HTML, and document downloads are
usually .pdf (e.g. http://www.odfalliance.org/resources.php), so what can
you say when the chef doesn't eat their own cooking.
2) Focus on content.
Personally, I'm interested in collecting/creating some fairly simple, but
nonetheless potentially lifesaving, public health content and to the extent
that I can afford to be, I am mostly disinterested in the arcana of
incompatibilities between competing open-source file formats. The "low
hanging fruit" content (WHO, UNESCO, NIH, etc.) that can be used to rapidly
bootstrap a health content library is mostly available in HTML or PDF
formats. If converting from PDF, I plan to mostly use HTML.
3) Application agnostic (mostly).
HTML content will present via Browse instead of (presumably) Write, which
makes sense to me. I'd prefer to be application (specifically
word-processor) agnostic.
4) Internationalization / Localization.
Adopting a simple HTML layout will produce content that is readily
internationalized and localized via Pootle.
5) Harvesting tools
I'm reasonably familiar with tools for harvesting HTML content in
semi-automated fashion (e.g. wget, et al.) and Walter has offered up the
PERL scripts he used to internationalize/localize the HTML for
www.laptop.org I can hack PERL reasonably well if I have the llama book
nearby, so I've nearly got all of the elements of a facilitated content
harvesting operation.
6) Empower local control of final content.
Even after language localization and bundling, simple HTML is generally
suitable for further modification before use according to local
requirements. We don't have a fancy word for this, but I would coin the
term "regionalization" for that aspect of the content life-cycle. This will
be necessary to patch up the inevitable short-comings in the
cultural-competency or coverage of centrally-produced (essentially generic
primer) materials.
7) Widely understood, easily learned, easily edited
The web provides a substantial set of "open-source" samples (e.g. view page
source in any browser on any page) that generally allows even novice users
to learn enough HTML to perform simple edits (including addition or
subtraction of entire text/topic elements). Any text editor will do as a
reasonable authoring tool as long as syntax is kept pretty plain-vanilla.
Call it "tag soup" if you must, but it works, I've built and maintained
web-sites for years with nothing more complex than Notepad.
8) Advanced publication features not really essential
I like the 'beauty-of-design" elements that more sophisticated
layout/mark-up tools can provide as much as the next guy, but by-and-large
the target textual content are extremely simple documents, some text and a
picture or two. No point in over-engineering them, and particularly not into
formats that seem to be incompatible with the XO as deployed. I am all in
favor of complimenting textual content with activity (application)
mouse-n-click action, but I'm not going to be doing any coding in Python, so
I'll stick to my knitting on the textual content side.
That's my argument in favor of HTML, you are certainly free to use whatever
(open) format you want for the content that you plan to contribute, although
some are clearly more suitable than others.
>
>
> > instead of .pdf if
> > that helps any with reformating tasks.
>
> The Free Software Inkscape editor allows minor editing of PDF files,
> if you tell it to import text as text when opening the PDF file. Just
> double-click any text block to edit. It won't reflow paragraphs.
>
> You can also select all text in most PDF readers to copy and paste
> into word processors. This preserves fonts and some other formatting,
> but loses layout.
>
> Scribus is the most powerful Free Software publishing program. You
> should edit text in other programs, and drop it into a Scribus layout
> when it is finished.
>
> I am a professional tech writer. I would be happy to assist with other
> publishing questions.
That's good to know and thanks for the offer. There are certainly plenty of
valuable contributions you could make towards improving OLPC's "capacity"
(empowering other volunteers), particularly by lowering the
barriers-to-entry for subject matter experts to contribute within their own
fields. Concise explanations and improved wiki organization on the more
technical aspects of creating internationalized (localization-ready) content
sound like a good starting point for you. Are there an examples of your
work on behalf of OLPC documentation on the wiki? I'm going to be
documenting my own process as an example (either sterling or cautionary) to
others, although admittedly that slows down the production rate, I do
believe in the importance of documentation.
My own background is described briefly on my user-page (
http://wiki.laptop.org/go/User:Cjl) with links to some of my (mostly)
scholarly publications. My wife happens to be an award-winning free-lance
medical writer specializing in patient-centric medical education (
http://www.mediabistro.com/WendyLeonard) who is currently working on her
Ph.D. in Public Health & Epidemiology.
>
> > Direct links provided in refactored
> > list.
> >
> > cjl
>
> --
> Edward Cherlin
> End Poverty at a Profit by teaching children business
> http://www.EarthTreasury.org/ <http://www.earthtreasury.org/> <
http://www.earthtreasury.org/>
> "The best way to predict the future is to invent it."--Alan Kay
>
------=_Part_15854_25127881.1210004506392
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<div> </div>
<div>Weird, gmail munged that last message into two incomprehensible pieces, here's a resend.</div>
<div> </div>
<div> </div>
<div>On Sun, May 4, 2008 at 6:02 PM, Edward Cherlin <echerlin at <a href="http://gmail.com/" target="_blank">gmail.com</a>> wrote:</div>
<p>> On Fri, Apr 25, 2008 at 8:08 AM, Chris Leonard <cjlhomeaddress at <a href="http://gmail.com/" target="_blank">gmail.com</a>><br>> wrote:<br>> > Mel,<br>> ><br>> > I refactored that page a bit, turns out there are some additional<br>
> stories<br>> > (another 8) on the UNESCO site (original) that Child-to-Child hadn't<br>> > reposted on their site. Some of them are posted in .doc<br>><br>> Can we use .odt, please?</p>
<p><br>Short question, long answer.</p>
<p>I think you may have misinterpreted my message, allow me to clarify, what I<br>was saying was "posted by UNESCO on their site in .doc". I've got no<br>control over how they chose to post their materials, I'm just happy that<br>
they do so with specific copy-right free notices.</p>
<p>As for what format to employ when reformatting content for OLPC use,<br>OpenOffice .odt format isn't really a very useful option for the intended<br>purpose at the present time. I am leaning towards HTML (and the simpler,<br>
the better) for the materials that I'm working to collect/compile/reformat.</p>
<p><br>Allow me me lay out some of my reasoning.</p>
<p>1) .odt just doesn't work on my XO.<br>I attempted opening sample .odt files on my G1G1 XO and it doesn't work. From what I can see there is no reason to expect that it would. As I understand it, Write is derived from AbiWord and even full native AbiWord doesn't support .odt import/export without additional plug-ins.</p>
<p>For reference see:<br><a href="http://www.abisource.com/wiki/OpenDocument_support" target="_blank">http://www.abisource.com/wiki/OpenDocument_support</a><br>and mailing list post referenced within</p>
<p>I'm not inclined to spend any more time on trying to sort this out as .odt is not a file type that I routinely encounter, and I see no reason to spend time on it when adequate alternatives exist for my purpose and it works beautifully on the XO as deployed. I was hard-pressed to even find an example .odt file to test, as most ODF websites doesn't use .odt very much, the pages themselves are of course in HTML, and document downloads are usually .pdf (e.g. <a href="http://www.odfalliance.org/resources.php" target="_blank">http://www.odfalliance.org/resources.php</a>), so what can you say when the chef doesn't eat their own cooking.</p>
<p>2) Focus on content.<br>Personally, I'm interested in collecting/creating some fairly simple, but<br>nonetheless potentially lifesaving, public health content and to the extent<br>that I can afford to be, I am mostly disinterested in the arcana of<br>
incompatibilities between competing open-source file formats. The "low<br>hanging fruit" content (WHO, UNESCO, NIH, etc.) that can be used to rapidly<br>bootstrap a health content library is mostly available in HTML or PDF<br>
formats. If converting from PDF, I plan to mostly use HTML.</p>
<p>3) Application agnostic (mostly).<br>HTML content will present via Browse instead of (presumably) Write, which<br>makes sense to me. I'd prefer to be application (specifically<br>word-processor) agnostic.</p>
<p>4) Internationalization / Localization.<br>Adopting a simple HTML layout will produce content that is readily<br>internationalized and localized via Pootle.</p>
<p> 5) Harvesting tools<br>I'm reasonably familiar with tools for harvesting HTML content in<br>semi-automated fashion (e.g. wget, et al.) and Walter has offered up the<br>PERL scripts he used to internationalize/localize the HTML for<br>
<a href="http://www.laptop.org/" target="_blank">www.laptop.org</a> I can hack PERL reasonably well if I have the llama book<br>nearby, so I've nearly got all of the elements of a facilitated content<br>harvesting operation.</p>
<p>6) Empower local control of final content.<br>Even after language localization and bundling, simple HTML is generally<br>suitable for further modification before use according to local<br>requirements. We don't have a fancy word for this, but I would coin the<br>
term "regionalization" for that aspect of the content life-cycle. This will<br>be necessary to patch up the inevitable short-comings in the<br>cultural-competency or coverage of centrally-produced (essentially generic<br>
primer) materials.</p>
<p>7) Widely understood, easily learned, easily edited<br>The web provides a substantial set of "open-source" samples (e.g. view page<br>source in any browser on any page) that generally allows even novice users<br>
to learn enough HTML to perform simple edits (including addition or<br>subtraction of entire text/topic elements). Any text editor will do as a<br>reasonable authoring tool as long as syntax is kept pretty plain-vanilla.<br>
Call it "tag soup" if you must, but it works, I've built and maintained<br>web-sites for years with nothing more complex than Notepad.</p>
<p>8) Advanced publication features not really essential<br>I like the 'beauty-of-design" elements that more sophisticated<br>layout/mark-up tools can provide as much as the next guy, but by-and-large<br>the target textual content are extremely simple documents, some text and a<br>
picture or two. No point in over-engineering them, and particularly not into<br>formats that seem to be incompatible with the XO as deployed. I am all in<br>favor of complimenting textual content with activity (application)<br>
mouse-n-click action, but I'm not going to be doing any coding in Python, so<br>I'll stick to my knitting on the textual content side.</p>
<p>That's my argument in favor of HTML, you are certainly free to use whatever<br>(open) format you want for the content that you plan to contribute, although<br>some are clearly more suitable than others.</p>
<p><br>><br>><br>> > instead of .pdf if<br>> > that helps any with reformating tasks.<br>><br>> The Free Software Inkscape editor allows minor editing of PDF files,<br>> if you tell it to import text as text when opening the PDF file. Just<br>
> double-click any text block to edit. It won't reflow paragraphs.<br>><br>> You can also select all text in most PDF readers to copy and paste<br>> into word processors. This preserves fonts and some other formatting,<br>
> but loses layout.<br>><br>> Scribus is the most powerful Free Software publishing program. You<br>> should edit text in other programs, and drop it into a Scribus layout<br>> when it is finished.<br>><br>
> I am a professional tech writer. I would be happy to assist with other<br>> publishing questions.</p>
<p><br>That's good to know and thanks for the offer. There are certainly plenty of<br>valuable contributions you could make towards improving OLPC's "capacity"<br>(empowering other volunteers), particularly by lowering the<br>
barriers-to-entry for subject matter experts to contribute within their own<br>fields. Concise explanations and improved wiki organization on the more<br>technical aspects of creating internationalized (localization-ready) content<br>
sound like a good starting point for you. Are there an examples of your<br>work on behalf of OLPC documentation on the wiki? I'm going to be<br>documenting my own process as an example (either sterling or cautionary) to<br>
others, although admittedly that slows down the production rate, I do<br>believe in the importance of documentation.</p>
<p>My own background is described briefly on my user-page (<a href="http://wiki.laptop.org/go/User:Cjl" target="_blank">http://wiki.laptop.org/go/User:Cjl</a>) with links to some of my (mostly)<br>scholarly publications. My wife happens to be an award-winning free-lance<br>
medical writer specializing in patient-centric medical education (<br><a href="http://www.mediabistro.com/WendyLeonard" target="_blank">http://www.mediabistro.com/WendyLeonard</a>) who is currently working on her<br>Ph.D. in Public Health & Epidemiology.</p>
<p><br>><br>> > Direct links provided in refactored<br>> > list.<br>> ><br>> > cjl<br>><br>> --<br>> Edward Cherlin<br>> End Poverty at a Profit by teaching children business<br>> <a href="http://www.earthtreasury.org/" target="_blank">http://www.EarthTreasury.org/</a> <<a href="http://www.earthtreasury.org/" target="_blank">http://www.earthtreasury.org/</a>><br>
> "The best way to predict the future is to invent it."--Alan Kay<br>><br></p>
------=_Part_15854_25127881.1210004506392--
More information about the Health
mailing list