I am going to do some research into *2odf in python.
On Jul 5, 2011 11:57 PM, "Dave Fisher" <[email protected]> wrote: > > On Jul 5, 2011, at 2:53 PM, Wolf Halton wrote: > >> As far as preparing literal books, it would help to know if the page content >> is stored as records in a database. That would make exporting to the book >> simpler, using sql to predesigned report templates. In my experience, almost >> no web images are of high enough quality for inclusion in professionally >> published material. > > Page content will be files in a hierarchy of some kind stored in an svn repository. > > Many possible transformations are possible using python markdown and the Apache CMS. > > >> I would like to help with this if possible. I am thinking a off compressed >> file could be broken into its 3 parts, export the database as text or xml >> and resave it as an odf compressed file. This looks relatively simple, even >> with placing the images. Thus it is probably full of minefields. > > Yes, but it is a good idea to have a *2ODF conversion. If we create an xml or xhtml of some type using python markdown we should be able to transform it to ODF somehow. > > Images can start with website level and we can worry about publishing quality later - I wonder how many will actually print. > > I am thinking about how to manage the selection of foreign language content in this web flow and your XML2ODF module would be a critical tool. > > I wonder if the ODF Toolkit would be helpful here. > > If we do this correctly the ODF option will be available to any Apache project using the CMS. > > Regards, > Dave > >> >> Cheers >> Wolf >> >> On Jul 5, 2011 1:57 PM, "Dave Fisher" <[email protected]> wrote: >>> >>> On Jul 5, 2011, at 10:33 AM, Rob Weir wrote: >>> >>>> On Tue, Jul 5, 2011 at 5:04 AM, Graham Lauder <[email protected]> >> wrote: >>>>> On Sun, 2011-07-03 at 10:23 -0700, Dave Fisher wrote: >>>>>> On Jul 2, 2011, at 9:29 PM, Graham Lauder wrote: >>>>> >>>>> >>>>>>> >>>>>>> Much of what is on there is legacy material that could be seriously >>>>>>> pruned. For instance all the old Marketing material that is V2.0 and >>>>>>> earlier could be deleted. >>>>>> >>>>>> What would you do to the main openoffice.org site if you were starting >> from scratch? >>>>> >>>>> Big question, moving to Apache has one big advantage from my POV. >>>>> (I should point out that my POV is marketing centric and is End User >>>>> focussed rather than developer focussed.) >>>>> >>>>> With the content going onto CMS it makes it a lot easier for marketing >>>>> content to be updated and changed as required. The Collabnet setup was >>>>> difficult. >>>>> >>>>> The OOo web presence is huge, not just the website itself but all the >>>>> NLC projects, the services part, maillists, forums, downloads and so on. >>>>> Each fragment is looked after by it's own team. There are overlaps (ie: >>>>> Distribution and CDROM) and global projects (Renaissance, art, UX) each >>>>> piece has it's user base and it's client base and so the website as an >>>>> entirety, obviously has to reflect that. >>>>> >>>> >>>> Yes, there were a lot of teams. Everyone seemed to have an official >>>> project title, often several ;-) >>>> >>>> We had some earlier discussions on this. Personally, I was proposing >>>> that we take the opportunity to simplify. For example, right now >>>> we're doing all the work on ooo-dev. At some point it will be clear, >>>> perhaps soon, that we need an ooo-user list. And maybe a few others. >>>> But I'd resist the urge to recreate the byzantine complexity of OOo >>>> until we're sure that we need it. I'm hoping we never do. >>> >>> If you read my initial email in this thread you will know that is where it >> started. Keeping the list to the 6 basic categories which I noted paralleled >> your Project Plan layout though not exactly. >>> >>>> >>>> >>>>> The home page as it is now was designed originally with one overriding >>>>> goal: "increase downloads." >>>>> >>>> >>>> Do you think this should still be the overriding goal of the homepage? >>>> >>>>> Therefore we had to analyse our catchment, identify our user groups and >>>>> their specific needs and patterns of usage of the Website. We then >>>>> needed to specifically identify the Home page users and their needs. It >>>>> should be noted that while there is a crossover, Homepage users are a >>>>> different set to Website users. Regular community members tend to >>>>> bypass the homepage because they know where they can fulfil their needs >>>>> already, they either go straight to the wiki or the forums or docs or >>>>> whichever part is specific to their part of the community. >>>>> >>>>> IMS We identified 5 groups that visit the Homepage. >>>>> >>>>> Casual arrivals >>>>> People seeking a download, either for the first time or to upgrade >>>>> Users seeking assistance >>>>> People wishing to contribute to the community >>>>> Developers >>> >>> He said they did an analysis. From my own experience the Home page is the >> hardest page in the whole site to design. >>> >>> For the new openoffice.org I would keep these key - dynamic buttons. The >> top bar and right news sections are another story - the page frame story >> which needs to be integrated with the openoffice.apache.org site. >>> >>>>> >>>> >>>> What is a "casual arrival"? Is that someone arriving via a search? >>>> >>>> >>>> Have you ever seen any traffic reports for Openoffice.org? Or >>>> something like Google Analytics, that would show how the web site is >>>> being used currently? >>>> >>>> >>>>> Each of these groups have entirely different needs. The original home >>>>> page tried to cater for all these different groups and ended up doing it >>>>> badly. My intention for the homepage was to have each of these groups >>>>> headed to wherever they needed to be on the website within 15 seconds. >>>>> We did that by reducing the number of decisions and introducing the >>>>> "Action Statements". (There were over 120 links on the original homepage >>>>> we reduced them to about 15, not including those in the news column.) >>>>> >>>>> Did it achieve More Downloads? as far as I know, yes. Louis would be >>>>> better informed on this. A lot of debate went on with regard to the >>>>> concept of the "Action Statements", over many months, but once the web >>>>> team were onside the results were, to my eyes, spectacular. >>>>> >>>>> (Just for amusements sake >>>>> >> http://wiki.services.openoffice.org/mwiki/images/a/a3/Home_page_draft_11-27.jpgwas >> my first rather amateurish mockup which the website team, Maarten, >> Kay, >> Ivan and others turned into http://www.openoffice.org .) >>> >>> It is important to note who has contributed to this process. >>> >>>>> >>>>> So the homepage is simply a portal, a signpost that is geared to cater >>>>> to the Unsophisticated End User. These people require simplicity, >>>>> continuity and a feeling of security and it is only this group that the >>>>> warmth and comfort of http://www.openoffice.org would be significant or >>>>> necessary. >>>>> >>>>> So, keep the home page as is or find someway to get the CMS to display >>>>> it, action statements intact at least. >>>>> >>>>> Then to my mind the only subs to the OOo domain that I would think that >>>>> would be compulsory would be: >>>>> support.openoffice.org >>>>> Why.openoffice.org and >>>>> download.openoffice.org >>>>> >>>>> and the NLC subdomains >>>>> >>>>> The rest of the website could happily exist under OpenOffice.apache.org. >>>>> >>>> >>>> This is close to what I was proposing. Move the project-centric >>>> services and content, the stuff that project volunteers access most, >>>> to the Apache address. But keep OpenOffice.org as the public-facing, >>>> user-facing portal for the product. >>> >>> This is what I hoped would be proposed. >>> >>> If you look in an earlier message I proposed a strategy: >>> >>> (1) An initial test could focus on the current main page in English >> followed by versions in several languages. This will need to script the >> conversion of existing webcontent from Kenai into format for the Apache CMS. >>> >>> -> This becomes the openoffice.org effort. >>> >>> (2) A second focus would be on the Kenai content for one of the product >> development areas. This script may be substantially different. >>> >>> -> This becomes part of the openoffice.apache.org effort. >>> >>> (3) A third focus would be building the documentation area. If a wiki is >> preferred then we should create a website page that provides good links. >>> >>> -> Jean and others have expressed wanting to have a reset here. >>> >>> (4) A fourth focus for the website migration is how to best integrate the >> project's choices for Bugzilla or JIRA, user forums, and mailing lists. >>> >>> -> This becomes a focus on the site skeleton and internal navigation. >>> >>> >>> I created a script here - ./trunk/tools/dev/fetch-all-web.sh to download >> webcontent from the svn. Like the hg to svn work this process must be >> repeatable by anyone who wants to run it. >>> >>> Regards, >>> Dave >>> >>>> >>>> >>>>> Cheers >>>>> for now >>>>> >>>>> GL >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Regards, >>>>>> Dave >>>>>> >>>>>> >>>>>>> >>>>>>> Argument could be made for the marketing material to start from >> scratch. >>>>>>> Personally I'd like to see a whole new branding and get shot of the >> old >>>>>>> stuff, make the first Apache release: V4.0 (Historically, significant >>>>>>> global change has meant a whole number change in the version: V2 new >>>>>>> codebase, V3 Apple compatibility. I think this is significant enough: >>>>>>> pre V4 = LGPL license, V4 and later = ALV2) From a marketing POV it >>>>>>> gives us a handle to hang a campaign on. >>>>>>> >>>>>>> Cheers >>>>>>> GL >>>>>>> >>>>>>> -- >>>>>>> Graham Lauder, >>>>>>> OpenOffice.org MarCon (Marketing Contact) NZ >>>>>>> http://marketing.openoffice.org/contacts.html >>>>>>> >>>>>>> OpenOffice.org Migration and training Consultant. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>> >
