On 20.05.2014 23:38, Andrea Pescetti wrote:
On 19/05/2014 Andre Fischer wrote:
As one of the first tasks in the OOXML area I would like to propose to
redesign and re-implement the OOXML parser.
I can only agree with this one. We've already discussed it many times,
but even the many users who
On 19/05/2014 Andre Fischer wrote:
As one of the first tasks in the OOXML area I would like to propose to
redesign and re-implement the OOXML parser.
I can only agree with this one. We've already discussed it many times,
but even the many users who prefer ODF need a good support for OOXML for
On 05/19/2014 11:57 PM, Andre Fischer wrote:
> On 20.05.2014 00:28, Kay Schenk wrote:
>> [top posting for a moment]
>>
>> Thank you for this initial introduction to planning better support for
>> OOXML. The reality is this is necessary, and I would imagine most
>> involved in the project realize
On 20.05.2014 00:28, Kay Schenk wrote:
[top posting for a moment]
Thank you for this initial introduction to planning better support for
OOXML. The reality is this is necessary, and I would imagine most
involved in the project realize this. OK, just a bit more below.
On 05/19/2014 06:39 AM, An
[top posting for a moment]
Thank you for this initial introduction to planning better support for
OOXML. The reality is this is necessary, and I would imagine most
involved in the project realize this. OK, just a bit more below.
On 05/19/2014 06:39 AM, Andre Fischer wrote:
> As one of the first
As one of the first tasks in the OOXML area I would like to propose to
redesign and re-implement the OOXML parser.
At the moment each application has its own OOXML import design. Those of
Impress and Calc are basically classic hand written push parser designs
while that of Writer is semi-autom
