#4165 BLOC First D: Write must expose UI to allow specifying output format...

[Zarro Boogs per Child]

#4165: Write must expose UI to allow specifying output format...
---------------------------------------+------------------------------------
  Reporter:  jg                        |       Owner:  uwog                  
      Type:  enhancement               |      Status:  new                   
  Priority:  blocker                   |   Milestone:  First Deployment, V1.0
 Component:  write-activity (abiword)  |     Version:                        
Resolution:                            |    Keywords:                        
  Verified:  0                         |  
---------------------------------------+------------------------------------

Comment(by walter):

 Preamble: We want to support open document formats and these formats
 should be the default for every activity.

 (1) identify the feature (4165)

 The Write activity should have mechanism(s) for specifying the format
 of its output. This is typically implemented as a feature in the "Save
 As" dialog (and associated with the CTRL-SHIFT-S keyboard shortcut).
 The document format is either specified  by suffix, by a pull-down
 dialog, or both. Most writing applications also let a default
 preference be set, through various means, perhaps the simplest being a
 check box as part of the Save As dialog.

 Since we write to the Journal and never invoke a Save or Save As
 dialog* it would make sense to add this as a dialog as a dialog on a
 tab. Eben should chime in as this seems to be precedent setting.

 * It seems that Save As will eventually subsumed in the Journal by the
 versioning mechanism.

 (2) use cases

 My primary use case would be for doing things like forcing the output
 of a document to a different format, such as HTML. Or, if I was using
 Write to write code, I may want to change the suffix to .py or .cs,
 etc.

 Kim's first use case, wanting to hand off a file to someone who
 doesn't have an XO has are certainly some merit; while most non-XO
 systems can readily support open file formats, there are certainly
 people who don't have such support enabled and, unfortunately, many
 situations where a proprietary format is required. While we shouldn't
 be encouraging this use case, we should not go out of our way to make
 it difficult for people to use their legacy tools.

 I don't think the printer use case is relevant, as that conversion is
 done in the print driver.

 (3) Is the feature only for G1G1 program?

 I think it is actually more important for our developing world
 deployment; using external resources to do the conversion is more easy
 to imagine in the context of G1G1, but if this is the only computer
 you have access to, you'd want to be able to do the type-conversions
 locally.

 (4) is this meant to be a UI pull down choice for the kids

 I leave it to Uwog, Eben and the Abiword team to decide the proper
 mechanism, but yes, it is very much meant for "the kids."

 (5) for FRS we will probably want to choose the one default format and
 not provide the UI choice

 We have a default choice already: I believe it is ODT. If we don't
 provide a UI choice, how are we addressing the bug?

-- 
Ticket URL: <https://dev.laptop.org/ticket/4165#comment:7>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system