<div dir="ltr"><div>Thanks Peter for the answer !</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">About half of the conf file entries are derived from the module and we 
have tools to automatise this , but conversely the other half is not. 
FWIW, the derived part is mostly that which is needed to function , 
while the not automatic one is needed to inform the reader .<br></blockquote><div>The thing is, from what I can see pretty much all fields from the conf file have an equivalent header specified in OSIS.<br></div><div>(Except for the technical fields specific to the sword module itself, like the data path, driver, compression method, etc.)</div><div><br></div><div>So it would be nice, at least, if osis2mod was able to output a module archive directly, including the conf file and the folder structure, so we wouldn't have additional manual actions.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Modules can have a large number of versifications which means that your blob of text in the last verse goes away, mostly. <br></blockquote><div><br></div><div>I don't understand what you mean by that. Do you mean that a single bible module can have several distinct versifications for different books ?</div><div>Because that seems contrary to everything I've seen so far.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There have been discussions re OSIS direct and the thought was this not useful</blockquote><div><br></div><div>Do you have a link to these discussions ? I'm curious about the arguments.<br></div><div><br></div><div>I'd argue that it only appears "not useful" due to the force of habit restricting your imagination ;-)</div><div>Quite similarly to our former discussion in jsword, where you considered it "feature-complete" because it matched the use cases identified many years ago - whereas in practice every current user has forked it to keep evolving.</div><div><br></div><div>The complexity of the current format practically enforces a single workflow to work with modules : the current workflow where there are "expert" repository owners, all with technical knowledge to generate and host modules - and where each module is slowly built and updated with care.<br></div><div>On the contrary, accepting files in clear and easy to write standard format (here, OSIS) would open up the usage drastically in ways you do not currently imagine - like my current objective of generating documents dynamically from remote sources and have them immediately ready to import.</div><div><br></div><div><br></div><div>Best regards,</div><div><br></div><div>Arnaud<br></div><div><br></div></div>