Hi Gabriela,

I’ve just added a new version of ODFConverter, which is actually called 
ODFTextConverter and is located in DocFormats/filters/odf/src/text/. The reason 
I’ve used the latter name is to distinguish it from classes like 
ODFPresentationConverter and ODFSheetConverter which we may have in the future 
if we add support for presentations and spreadsheets (for OOXML, ‘Word’ takes 
the place of ‘Text’).

I actually suggest ignoring the Word filter for the time being, because it’s 
large and complex and likely to provide more confusion than assistance. 
Instead, start simple and just think about the get operation for now - that is, 
creating a new HTML file from an existing .odt file. This doesn’t require most 
of the bells and whistles present in the Word code and is a *much* simpler task 
than worrying about updates.

In fact, ODFTextConverter isn’t strictly necessary for this task in its basic 
form. The purpose of WordConverter is a convenient place to hold state 
information that is needed during the conversion process, to avoid having to 
pass the necessary variables around as a parameter to each function. 
ODFTextConverter will become important a bit further on in your implementation 
of get, like when you start dealing with styles (thus needing a reference to 
the stylesheet data you’ve extracted from the document), and images (needing 
access to the storage object representing the directory where the HTML file 
is). I’ve supplied the converter as a parameter to traverseContent() in 
ODFText.c, but you won’t need it just yet.

Also in ODFText.c I’ve started the implementation of ODFTextGet() and put in 
some instructions for the first steps. Essentially you need to traverse the DOM 
tree of the content.xml file from the .odt file (which is already parsed and 
provided to you as package->contentDoc), and as you do so, add elements to the 
HTML file. Right now, this just prints out the name of elements it encounters 
to the terminal, and the result is an empty HTML file. Start by doing things 
like checking if the current ODF node is a paragraph node or text node, and 
create the corresponding HTML element for that.

Let’s take this as a first phase; it should be possible to do basic get 
conversion entirely inside ODFText.c without there being changes necessary to 
any other files (though of course if you need to do so, go ahead). Once you’ve 
made some progress on this or get stuck, let me know and I’ll answer any 
questions you have.

—
Dr Peter M. Kelly
pmke...@apache.org

PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

> On 25 Apr 2015, at 10:17 pm, Gabriela Gibson <gabriela.gib...@gmail.com> 
> wrote:
> 
> Thank you very much :)
> 
> G
> 
> On Sat, Apr 25, 2015 at 4:12 PM, Peter Kelly <pmke...@apache.org> wrote:
> 
>> The revert failed because it conflicted with some fixes I made to
>> OOXMLTypedefs.h, to remove compiler warnings about duplicate typedefs.
>> 
>> ‘git revert’ essentially takes a diff between the files before and after a
>> given commit, and then applies that patch in reverse. So if changes have
>> been made after the the commit was reverted, then the patch may fail to
>> apply (as it did in this case).
>> 
>> There’s two ways to get around this:
>> 1. Revert all the commits, in reverse order, until you get back to where
>> you were previously
>> 2. Check out files from the commit prior to when you started making the
>> changes in question (in this case from the stable branch).
>> 
>> I’ve just fixed this up manually now, using the second approach. There
>> were no other changes to those particular files between your commit the
>> other day and these, so I just replaced them directly.
>> 
>> I’ll now set up the structure under filters/odf/src with some comments, so
>> you can work from there.
>> 
>> —
>> Dr Peter M. Kelly
>> pmke...@apache.org
>> 
>> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
>> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>> 
>>> On 25 Apr 2015, at 9:28 pm, Gabriela Gibson <gabriela.gib...@gmail.com>
>> wrote:
>>> 
>>> I managed to revert 2 of the 3 commits I made, using a fresh clone, using
>>> 'push' after every revert.
>>> 
>>> 
>> https://github.com/apache/incubator-corinthia/commit/d929743bc35ef8446e3caf617ecc2fe06f271f87
>>> 
>> https://github.com/apache/incubator-corinthia/commit/af7174928444035dd05a63a1e1f2cb190fcb5360
>>> 
>>> However, the first commit of that series (I worked backwards) is not
>>> reverting trivially and I'm not sure how to proceed.
>>> 
>>> This is the state of play:
>>> 
>>> $ git revert c4ea2ed9389b46418eed7a1f499b8085461c58c3
>>> error: could not revert c4ea2ed... Add initial shape of ODF filter.
>>> hint: after resolving the conflicts, mark the corrected paths
>>> hint: with 'git add <paths>' or 'git rm <paths>'
>>> hint: and commit the result with 'git commit'
>>> 
>>> $git status
>>> On branch master
>>> Your branch is up-to-date with 'origin/master'.
>>> 
>>> You are currently reverting commit c4ea2ed.
>>> (fix conflicts and run "git revert --continue")
>>> (use "git revert --abort" to cancel the revert operation)
>>> 
>>> Changes to be committed:
>>> (use "git reset HEAD <file>..." to unstage)
>>> 
>>>       modified:   DocFormats/filters/odf/src/text/ODFText.c
>>> modified:   DocFormats/filters/ooxml/CMakeLists.txt
>>>       deleted:    DocFormats/filters/ooxml/src/odf/ODFConverter.c
>>>       deleted:    DocFormats/filters/ooxml/src/odf/ODFConverter.h
>>> 
>>> Unmerged paths:
>>> (use "git reset HEAD <file>..." to unstage)
>>> (use "git add <file>..." to mark resolution)
>>> 
>>>       both modified:
>>> DocFormats/filters/ooxml/src/common/OOXMLTypedefs.h
>>> 
>>> Untracked files:
>>> (use "git add <file>..." to include in what will be committed)
>>> 
>>>       TAGS
>>> 
>>> ------
>>> 
>>> The list in the git status looks like expected:
>>> 
>>> $ git status
>>> On branch master
>>> Your branch is up-to-date with 'origin/master'.
>>> 
>>> You are currently reverting commit c4ea2ed.
>>> (fix conflicts and run "git revert --continue")
>>> (use "git revert --abort" to cancel the revert operation)
>>> 
>>> Changes to be committed:
>>> (use "git reset HEAD <file>..." to unstage)
>>> 
>>>       modified:   DocFormats/filters/odf/src/text/ODFText.c
>>>       modified:   DocFormats/filters/ooxml/CMakeLists.txt
>>>       deleted:    DocFormats/filters/ooxml/src/odf/ODFConverter.c
>>> deleted:    DocFormats/filters/ooxml/src/odf/ODFConverter.h
>>> 
>>> Unmerged paths:
>>> (use "git reset HEAD <file>..." to unstage)
>>> (use "git add <file>..." to mark resolution)
>>> 
>>> both modified:      DocFormats/filters/ooxml/src/common/OOXMLTypedefs.h
>>> 
>>> Untracked files:
>>> (use "git add <file>..." to include in what will be committed)
>>> 
>>> TAGS
>>> 
>>> However I'm not sure what the both modifed entry signifies.
>>> 
>>> The changes to DocFormats/filters/ooxml/src/common/OOXMLTypedefs.h
>>> mentioned in 'both modified' I did in that commit were additions:
>>> 
>>> (logmessage entry for that change)
>>> * DocFormats/filters/ooxml/src/common/OOXMLTypedefs.h Copypasta and
>>> replace-string of Word related typedefs to 'ODFxxx'. Not clear they are
>> all
>>> needed or correct.
>>> 
>>> In the file itself at the end, the additions were removed and I now see
>>> this added in, presumably by git:
>>> 
>>> =======
>>>>>>>>>> parent of c4ea2ed... Add initial shape of ODF filter.
>>> 
>>> I'm not sure what is the conflict here or how to resolve it.
>>> 
>>> thanks,
>>> 
>>> G
>>> --
>>> Visit my Coding Diary: http://gabriela-gibson.blogspot.com/
>> 
>> 
> 
> 
> -- 
> Visit my Coding Diary: http://gabriela-gibson.blogspot.com/

Reply via email to