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 link intra
I'm not inclined to spend any 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 find an example .odt file to
test, as even 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/>
> "The best way to predict the future is to invent it."--Alan Kay
>
------=_Part_15664_5265500.1210002160931
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<br><br>
<div class="gmail_quote">On Sun, May 4, 2008 at 6:02 PM, Edward Cherlin <<a href="mailto:echerlin at gmail.com">echerlin at gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Fri, Apr 25, 2008 at 8:08 AM, Chris Leonard <<a href="mailto:cjlhomeaddress at gmail.com">cjlhomeaddress at gmail.com</a>> wrote:<br>
> Mel,<br>><br>> I refactored that page a bit, turns out there are some additional 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?</blockquote>
<div> </div>
<div>Short question, long answer.</div>
<div> </div>
<div>I think you may have misinterpreted my message, allow me to clarify, what I was saying was "posted by UNESCO on their site in .doc". I've got no control over how they chose to post their materials, I'm just happy that they do so with specific copy-right free notices.</div>
<div> </div>
<div>As for what format to employ when reformatting content for OLPC use, OpenOffice .odt format isn't really a very useful option for the intended purpose at the present time. I am leaning towards HTML (and the simpler, the better) for the materials that I'm working to collect/compile/reformat. </div>
<div> </div>
<div>Allow me me lay out some of my reasoning. </div>
<div> </div>
<div>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.</div>
<div> </div>
<div>For reference see:<br><a href="http://www.abisource.com/wiki/OpenDocument_support">http://www.abisource.com/wiki/OpenDocument_support</a><br>and mailing list post link intra</div>
<div> </div>
<div>I'm not inclined to spend any 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 find an example .odt file to test, as even 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">http://www.odfalliance.org/resources.php</a>), so what can you say when the chef doesn't eat their own cooking.</div>
<div> </div>
<div>2) Focus on content.<br>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.</div>
<div> </div>
<div>3) Application agnostic (mostly).<br>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.</div>
<div> </div>
<div>4) Internationalization / Localization.<br>Adopting a simple HTML layout will produce content that is readily internationalized and localized via Pootle. </div>
<div> </div>
<div>
<div>
<div>5) Harvesting tools</div>
<div>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 <a href="http://www.laptop.org/">www.laptop.org</a> 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. </div>
</div></div>
<div> </div>
<div>6) Empower local control of final content.<br>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.</div>
<div> </div>
<div>7) Widely understood, easily learned, easily edited<br>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.</div>
<div> </div>
<div>8) Advanced publication features not really essential<br>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><span id=""></span><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.</blockquote>
<div> </div>
<div>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.</div>
<div> </div>
<div>My own background is described briefly on my user-page (<a href="http://wiki.laptop.org/go/User:Cjl">http://wiki.laptop.org/go/User:Cjl</a>) 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 (<a href="http://www.mediabistro.com/WendyLeonard">http://www.mediabistro.com/WendyLeonard</a>) who is currently working on her Ph.D. in Public Health & Epidemiology.</div>
<div> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><span id=""></span><br>> Direct links provided in refactored<br>> list.<br>><br>> cjl<br>
<div>
<div></div>
<div class="Wj3C7c"><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><br>"The best way to predict the future is to invent it."--Alan Kay<br>
</div></div></blockquote></div><br>
------=_Part_15664_5265500.1210002160931--
More information about the Health
mailing list