[Health] Health books

Mon May 5 12:38:48 EDT 2008

AFAIK HTML is also easy to package as a content (.xol) bundle.

Also see,
http://wiki.laptop.org/go/Creating_a_content_bundle

Arjun

On Mon, May 5, 2008 at 9:12 PM, Chris Leonard <cjlhomeaddress at gmail.com> wrote:
>
>
>
> On Sun, May 4, 2008 at 6:02 PM, Edward Cherlin <echerlin at gmail.com> wrote:
>
> > On Fri, Apr 25, 2008 at 8:08 AM, Chris Leonard <cjlhomeaddress at gmail.com>
> wrote:
> > > Mel,
> > >
> > > I refactored that page a bit, turns out there are some additional
> stories
> > > (another 8)  on the UNESCO site (original) that Child-to-Child hadn't
> > > reposted on their site.  Some of them are posted in .doc
> >
> > Can we use .odt, please?
>
>
> Short question, long answer.
>
> 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.
>
> 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.
>
> Allow me me lay out some of my reasoning.
>
> 1) .odt just doesn't work on my XO.
> 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.
>
> 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/
> > "The best way to predict the future is to invent it."--Alan Kay
> >
>
>
> _______________________________________________
>  Health mailing list
>  Health at lists.laptop.org
>  http://lists.laptop.org/listinfo/health
>
>

-- 
Arjun Sarwal
http://dev.laptop.org/~arjs