Hello

[David Virden]

My name is David and I'm interested in assisting with technical
documentation. I have an English degree from the University of North Texas
and am pursuing a technical writing graduate certificate from University of
Texas at El Paso. I don't have much experience with technical writing other
than what I've done in the classroom, which is why I'm here.

, Additionally, I am taking some programming classes and have website
development experience. However, I'm mainly interested in writing at this
moment.

I look forward to helping.

Thanks,
David

Re: many many stlport issues...can anyone help

[Kay Schenk]

On Wed, Nov 20, 2013 at 9:34 AM, Kay Schenk  wrote:

>
> On Tue, Nov 19, 2013 at 11:33 PM, Herbert Duerr  wrote:
>
>> On 20.11.2013 02:00, Kay Schenk wrote:
>>
>>> I installed the stlport provided by opensuse for my version -- it is
>>> 4.6.2,
>>> whereas the latest one at Sourceforge is 5.2.1.
>>>
>>
>> Yes. Stlport 4.6.2 was getting a bit old. As the latest maintenance
>> version of the stlport4 series it was released in 2004. So Stlport 4 has
>> been unmaintained for almost ten years now.
>>
>> Since AOO 4 we are using the compiler/system provided STL and not stlport
>> 4. We are lucky that the STL variants have been standardized with [1], so
>> we can rely on them. Stlport 5.x follows this standard too, but Stlport 4
>> didn't, so it was no longer maintained. With AOO 4 we have abandoned it too.
>>
>> Please use the --without-stlport configure switch. Stlport 4 was great
>> for its time. OOo and AOO 3.x still used it many years after its last
>> maintenance version which is a reverence to stlport4. But with AOO 4 it was
>> overdue that we finally let it rest in peace. This gives AOO the chance to
>> become more compliant with the rest of the C++ world.
>>
>> [1] http://en.wikipedia.org/wiki/C++_Technical_Report_1
>>
>
> OK, I will look at this and thanks for this clarification. I got really
> confused over this. I did use --without- stlport, but for some reason I
> thought this meant use a system supplied one -- different from stdlibs,
> which I normally install, so that's why all this tangle. So, I will
> deinstall stlport 4.x, and see what happens.
>
>
>> A lot more work is needed to change all the many parts of the source code
>> that use pre-standard STL constructs to their standard compliant
>> counterparts. But the heavy lifting is already done and the individual
>> adaptions can be done automatically by some scripting.
>>
>>
>>  Should I install the newer version --  with gcc 4.7.2 in use.
>>>
>>
>> You don't need stlport4 any longer. Please use the --without-stlport
>> configure switch. The gcc provided libstdc++ library, boost/tr1 [2] and our
>> stl wrappers will replace it just fine.
>>
>> [2] http://www.boost.org/doc/libs/1_54_0/doc/html/boost_tr1.html
>>
>>
>>  Also, I see this page:
>>> http://www.stlport.org/doc/vendor_interface.html
>>>
>>> and since I seem to be getting a LOT of redefinition errors from what I'm
>>> seeing, is this a namespace problem on my system? I also have C stdlib
>>> installed.
>>>
>>
>> Yes, the stdlib and the stdc++ libs are the standard libraries available
>> on almost all Unixes nowadays.
>
>
> OK, I will recheck.
>
>
>> That's why we prefer using these libraries to provide the STL
>> functionality we need. Having such native libs is much better than us
>> shipping some an old stlport4 binary that is based on long unmaintained
>> versions of a non-standard compliant library.
>>
>>
>>  Finally, in order to do anything, I had to muck with the include (-I)
>>> definitions since stlport was not in the generated includes. Maybe we
>>> need
>>> to fix this since it's no longer provided locally?
>>>
>>> All was more or less fine with my setup until this change -- now things
>>> are
>>> not happy.
>>>
>>
>> Please use the --without-stlport configure switch.
>>
>> This option is the new default. Thanks to Jan for fixing configure.in.
>> But you'd need to update to the newest trunk version to benefit from Jan's
>> fix.
>>
>
> right -- I did that...
>
>
> OK, thanks -- I'll get back to this...
>
>
>>
>> Herbert
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>
>
>
> --
>
> -
> MzK
>
> “Unless someone like you cares a whole awful lot,
>  Nothing is going to get better. It's not.”
>   -- Dr. Seuss, The Lorax
>

short update...in building  xml2cmp/source/finder

the reference to

#  include BOOST_TR1_STD_HEADER(utility) in

../boost/tr1/detail/config_all.hpp

fails for me either from the externally installed boost or my local
install. I have no idea why this never happened before the stlport removal
but there you have it. I guess to make this work, I will need to define
BOOST_TR1_STD_HEADER properly at least.



-- 
-
MzK

“Unless someone like you cares a whole awful lot,
 Nothing is going to get better. It's not.”
  -- Dr. Seuss, The Lorax

Re: [Proposal] Update Icons for AOO 4.1

[Samer Mansour]

I've been so busy at work in the last week, let me set myself a reminder to
review this on Saturday and give everyone an update and propose how to move
forward.


On Mon, Nov 18, 2013 at 4:47 AM, Jürgen Schmidt wrote:

> On 11/4/13 8:23 PM, Samer Mansour wrote:
> > This is just a reminder that this coming Nov 9th is the end of the 30 day
> > window for list folk to submit ideas, whether in words or images.
> >
> > After this date, I will compile the ideas and feedback.
>
> Hi Samer,
>
> any news on this? I believe we should integrate new icons as soon as
> possible
>
> Juergen
>
>
> >
> > Samer Mansour
> >
> >
> > On Wed, Oct 9, 2013 at 11:01 PM, Samer Mansour 
> wrote:
> >
> >> Hello,
> >>
> >> I'm proposing to have the icons (and related assets) updated for AOO 4.1
> >> release. I would like to take the responsibility to see this gets done.
> >>
> >> Here is the icons that need to be updated:
> >>
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO4.1+-+Desktop+Icons
> >>
> >> Related asset:
> >>
> >>
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO4.1+-+Application+And+Launcher
> >>
> >> You can see two examples of ideas on the first link. You can also
> suggest
> >> your own ideas verbally by commenting on the wiki page or visually by
> >> attaching it to the wiki. (Please don't reply ideas in this mailing
> list,
> >> let us know if you have trouble)
> >>
> >> I am putting a deadline for the idea submission and discussion in 30
> days,
> >> November 9th, 2013.
> >> Once we reach the deadline, we will have a separate discussion for
> >> optimizing for the best user experience.
> >>
> >> This is not a contest or a call for public proposals. This is regular,
> >> needs to be done, no-bikeshedding-please work. When the deadline Nov 9th
> >> arrives, if there is more than one viable solution, we will try to reach
> >> consensus without a end user vote.
> >> eg. We will not be doing what we did with the logo, that was a special
> >> case because it is the face of AOO.
> >>
> >> Samer Mansour
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: many many stlport issues...can anyone help

[Kay Schenk]

On Tue, Nov 19, 2013 at 11:33 PM, Herbert Duerr  wrote:

> On 20.11.2013 02:00, Kay Schenk wrote:
>
>> I installed the stlport provided by opensuse for my version -- it is
>> 4.6.2,
>> whereas the latest one at Sourceforge is 5.2.1.
>>
>
> Yes. Stlport 4.6.2 was getting a bit old. As the latest maintenance
> version of the stlport4 series it was released in 2004. So Stlport 4 has
> been unmaintained for almost ten years now.
>
> Since AOO 4 we are using the compiler/system provided STL and not stlport
> 4. We are lucky that the STL variants have been standardized with [1], so
> we can rely on them. Stlport 5.x follows this standard too, but Stlport 4
> didn't, so it was no longer maintained. With AOO 4 we have abandoned it too.
>
> Please use the --without-stlport configure switch. Stlport 4 was great for
> its time. OOo and AOO 3.x still used it many years after its last
> maintenance version which is a reverence to stlport4. But with AOO 4 it was
> overdue that we finally let it rest in peace. This gives AOO the chance to
> become more compliant with the rest of the C++ world.
>
> [1] http://en.wikipedia.org/wiki/C++_Technical_Report_1
>

OK, I will look at this and thanks for this clarification. I got really
confused over this. I did use --without- stlport, but for some reason I
thought this meant use a system supplied one -- different from stdlibs,
which I normally install, so that's why all this tangle. So, I will
deinstall stlport 4.x, and see what happens.


> A lot more work is needed to change all the many parts of the source code
> that use pre-standard STL constructs to their standard compliant
> counterparts. But the heavy lifting is already done and the individual
> adaptions can be done automatically by some scripting.
>
>
>  Should I install the newer version --  with gcc 4.7.2 in use.
>>
>
> You don't need stlport4 any longer. Please use the --without-stlport
> configure switch. The gcc provided libstdc++ library, boost/tr1 [2] and our
> stl wrappers will replace it just fine.
>
> [2] http://www.boost.org/doc/libs/1_54_0/doc/html/boost_tr1.html
>
>
>  Also, I see this page:
>> http://www.stlport.org/doc/vendor_interface.html
>>
>> and since I seem to be getting a LOT of redefinition errors from what I'm
>> seeing, is this a namespace problem on my system? I also have C stdlib
>> installed.
>>
>
> Yes, the stdlib and the stdc++ libs are the standard libraries available
> on almost all Unixes nowadays.


OK, I will recheck.


> That's why we prefer using these libraries to provide the STL
> functionality we need. Having such native libs is much better than us
> shipping some an old stlport4 binary that is based on long unmaintained
> versions of a non-standard compliant library.
>
>
>  Finally, in order to do anything, I had to muck with the include (-I)
>> definitions since stlport was not in the generated includes. Maybe we need
>> to fix this since it's no longer provided locally?
>>
>> All was more or less fine with my setup until this change -- now things
>> are
>> not happy.
>>
>
> Please use the --without-stlport configure switch.
>
> This option is the new default. Thanks to Jan for fixing configure.in.
> But you'd need to update to the newest trunk version to benefit from Jan's
> fix.
>

right -- I did that...


OK, thanks -- I'll get back to this...


>
> Herbert
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
-
MzK

“Unless someone like you cares a whole awful lot,
 Nothing is going to get better. It's not.”
  -- Dr. Seuss, The Lorax

Re: many many stlport issues...can anyone help

[Andre Fischer]

On 20.11.2013 12:26, jan i wrote:

On 20 November 2013 12:01, Andre Fischer  wrote:


On 20.11.2013 09:54, Herbert Duerr wrote:


On 20.11.2013 09:20, Andre Fischer wrote:


On 20.11.2013 08:33, Herbert Duerr wrote:


Please use the --without-stlport configure switch.

This option is the new default. Thanks to Jan for fixing configure.in.
But you'd need to update to the newest trunk version to benefit from
Jan's fix.



Is there any reason why we still need this option (be it default or
not)?


If there is a choice between step-wise evolution and a big-bang change
I'd always prefer the step-wise evolution.


I agree.  But I would like steps that go from valid state to valid state.
  From what I have heard I had the impression that the --without-stlport
option had only one valid value left and that using --with-stlport would
break the build.



   Is there any scenario where we would need that switch to turn on

support for stlport?


A developer reusing the latest recipes from our snapshots page would fail
with the latest trunk if the --without-stlport option was no longer
recognized.


Would it not be better to update the recipes?

I would assume that removing the configure option and adapting the build
recipes take just a couple of hours to do.  Would it not be better to spend
this additional time and make the change of removing support for stlport
complete in one step?


with my  change to configure.in, you can choose to use --without-stlport or
not it has he same effect, meaning developers do not need to change
configure options.


Thanks for cleaning this up.

What is the timeline for removing this option completely?

-Andre


rgds
jan I.



-Andre


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: many many stlport issues...can anyone help

[jan i]

On 20 November 2013 12:01, Andre Fischer  wrote:

> On 20.11.2013 09:54, Herbert Duerr wrote:
>
>> On 20.11.2013 09:20, Andre Fischer wrote:
>>
>>> On 20.11.2013 08:33, Herbert Duerr wrote:
>>>

 Please use the --without-stlport configure switch.

 This option is the new default. Thanks to Jan for fixing configure.in.
 But you'd need to update to the newest trunk version to benefit from
 Jan's fix.


>>> Is there any reason why we still need this option (be it default or
>>> not)?
>>>
>>
>> If there is a choice between step-wise evolution and a big-bang change
>> I'd always prefer the step-wise evolution.
>>
>
> I agree.  But I would like steps that go from valid state to valid state.
>  From what I have heard I had the impression that the --without-stlport
> option had only one valid value left and that using --with-stlport would
> break the build.
>
>
>>   Is there any scenario where we would need that switch to turn on
>>> support for stlport?
>>>
>>
>> A developer reusing the latest recipes from our snapshots page would fail
>> with the latest trunk if the --without-stlport option was no longer
>> recognized.
>>
>
> Would it not be better to update the recipes?
>
> I would assume that removing the configure option and adapting the build
> recipes take just a couple of hours to do.  Would it not be better to spend
> this additional time and make the change of removing support for stlport
> complete in one step?
>

with my  change to configure.in, you can choose to use --without-stlport or
not it has he same effect, meaning developers do not need to change
configure options.

rgds
jan I.


> -Andre
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: many many stlport issues...can anyone help

[Andre Fischer]

On 20.11.2013 09:54, Herbert Duerr wrote:

On 20.11.2013 09:20, Andre Fischer wrote:

On 20.11.2013 08:33, Herbert Duerr wrote:


Please use the --without-stlport configure switch.

This option is the new default. Thanks to Jan for fixing configure.in.
But you'd need to update to the newest trunk version to benefit from
Jan's fix.



Is there any reason why we still need this option (be it default or
not)?


If there is a choice between step-wise evolution and a big-bang change 
I'd always prefer the step-wise evolution.


I agree.  But I would like steps that go from valid state to valid 
state.  From what I have heard I had the impression that the 
--without-stlport option had only one valid value left and that using 
--with-stlport would break the build.





 Is there any scenario where we would need that switch to turn on
support for stlport?


A developer reusing the latest recipes from our snapshots page would 
fail with the latest trunk if the --without-stlport option was no 
longer recognized.


Would it not be better to update the recipes?

I would assume that removing the configure option and adapting the build 
recipes take just a couple of hours to do.  Would it not be better to 
spend this additional time and make the change of removing support for 
stlport complete in one step?


-Andre


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Shearing in 3D

[Armin Le Grand]

On 19.11.2013 23:41, Regina Henschel wrote:

Hi Armin,

Regina Henschel schrieb:

Hi Armin,

[..]


Of cause there might be an error in my simulation, but examine that, it
would be helpful to know, in which way the values of rShear are intended
to be used.


It was indeed an error in my simulation. Now it works fine.

 Can you write me down the matrices?


... ore even simpler in our code:
Look for B3DHomMatrix::shearXY, B3DHomMatrix::shearYZ and 
B3DHomMatrix::shearXZ which create these shear matrices. shearXY e.g. 
shears around the Z axis




Not needed any longer. A shear matrix is
1  rShear.X rShear.Y
0  1rShear.Z
0  0   1

Excuse me for bothering you.

Kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Shearing in 3D

[Armin Le Grand]

Hi Regina,

On 19.11.2013 23:41, Regina Henschel wrote:

Hi Armin,

Regina Henschel schrieb:

Hi Armin,

[..]


Of cause there might be an error in my simulation, but examine that, it
would be helpful to know, in which way the values of rShear are intended
to be used.


It was indeed an error in my simulation. Now it works fine.

 Can you write me down the matrices?


I can, but they are in the book you ordered :-)
You can also find them in the web on various places, e.g.


 /Matrix/ Algebra and Affine Transformations
 



http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=7&ved=0CFgQFjAG&url=http%3A%2F%2Fpeople.cs.clemson.edu%2F~dhouse%2Fcourses%2F401%2Fnotes%2Faffines-matrices.pdf&ei=35KMUtCkIoSI0AWSqYCwAw&usg=AFQjCNHHUeWtbq35mta06SdatTAKNVaR7A&bvm=bv.56643336,d.d2k&cad=rja

One more hint: Whenever looking at papers about this, three things are 
essential:
- the orientation of the homogen matrix may vary, there are two possible 
systems. Our interpretation uses the right column as translaton
- the multiplication order might vary in notation. Our interpretation 
multiplies matrices from the left

- matrix multiplication is not commutative



Not needed any longer. A shear matrix is
1  rShear.X rShear.Y
0  1rShear.Z
0  0   1

Excuse me for bothering you.


You never do ;-)



Kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org


--
ALG

Re: trunk build failure: ld: library not found for -lc++ in comphelper

[Pavel Janík]

Hi,

> Please update your trunk checkout (r1543407 or newer) and restart doing a 
> clean build.

the same. I already had up-to-date tree.
-- 
Pavel Janík




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: many many stlport issues...can anyone help

[Herbert Duerr]

On 20.11.2013 09:54, Herbert Duerr wrote:

[...]

So the AOO evolution of the configure option was/is:
1) encourage the use of --without-stlport
2) identify and solve all issues on all target platforms
3) make --without-stlport the default
4) remove obsoleted code parts
5) remove --without-stlport being tolerated after it has become the
default and it stopped being useful


Some important steps were missing in my previous mail. Here is a better 
description of the stepwise evolution:


1) implement --without-stlport support also for non-Linux platforms
2) encourage the use of --without-stlport for all platforms
3) identify and solve all issues on all target platforms
4) make --without-stlport the default
5) disallow the --with-stlport option and warn about it in configure
6) remove code parts obsoleted by the dropped stlport4 support
7) remove --without-stlport being tolerated after it has become the 
default and it stopped being useful


The current trunk has now passed step 6.

Herbert

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: trunk build failure: ld: library not found for -lc++ in comphelper

[Herbert Duerr]

Hi Pavel,

> current trunk on unxmacxi:


Pavel-Janiks-MacBook-Pro:comphelper pavel$ make
[ build LNK ] Library/libcomphelpgcc3.dylib
R=/Users/pavel/BUILD/BuildDir && S=$R/ooo_trunk_src && O=$S/solver/410/unxmacxi.pro && W=$O/workdir &&  
mkdir -p $W/LinkTarget/Library/ && DYLIB_FILE=`/usr/bin/mktemp -t gbuild.` && /usr/bin/perl 
$S/solenv/bin/macosx-dylib-link-list.pl  -dynamiclib -single_module -install_name 
'@__OOO/libcomphelpgcc3.dylib' -Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk  -L$O/lib 
-L/usr/lib  -luno_sal -luno_cppuhelpergcc3 -luno_cppu -lucbhelper4gcc3 -lvos3gcc3 -lc++  > ${DYLIB_FILE} && ccache 
/usr/bin/g++-4.0  -dynamiclib -single_module -install_name '@__OOO/libcomphelpgcc3.dylib' 
-Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk  -L$O/lib -L/usr/lib  -luno_sal -luno_cppuhelpergcc3 -luno_cppu -lucbhelper4gcc3 -lvos3gcc3 
-lc++   $W/CxxObject/comphelper/source/compare/AnyCompareFactory.o 
$W/CxxObject/comphelper/source/container/IndexedPropertyValuesContainer.o $W/CxxObject/comphelper/source/container/NamedPr

opertyValuesContainer.o ... $W/CxxObject/comphelper/source/xml/attributelist.o 
$W/CxxObject/comphelper/source/xml/ofopxmlhelper.o-o $W/LinkTarget/Library/libcomphelpgcc3.dylib 
`cat ${DYLIB_FILE}` &&  /usr/bin/perl $S/solenv/bin/macosx-change-install-names.pl Library OOO 
$W/LinkTarget/Library/libcomphelpgcc3.dylib && ln -sf 
$W/LinkTarget/Library/libcomphelpgcc3.dylib $W/LinkTarget/Library/libcomphelpgcc3.jnilib && rm 
-f ${DYLIB_FILE}

ld: library not found for -lc++
collect2: ld returned 1 exit status
make: *** 
[/Users/pavel/BUILD/BuildDir/ooo_trunk_src/solver/410/unxmacxi.pro/workdir/LinkTarget/Library/libcomphelpgcc3.dylib]
 Error 1
Pavel-Janiks-MacBook-Pro:comphelper pavel$



Please update your trunk checkout (r1543407 or newer) and restart doing 
a clean build.


Herbert

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: many many stlport issues...can anyone help

[Herbert Duerr]

On 20.11.2013 09:20, Andre Fischer wrote:

On 20.11.2013 08:33, Herbert Duerr wrote:


Please use the --without-stlport configure switch.

This option is the new default. Thanks to Jan for fixing configure.in.
But you'd need to update to the newest trunk version to benefit from
Jan's fix.



Is there any reason why we still need this option (be it default or
not)?


If there is a choice between step-wise evolution and a big-bang change 
I'd always prefer the step-wise evolution.


We don't NEED this option. We don't NEED individual commits either, all 
we NEED is a good next release. But a big-bang commit that would update 
AOO 4.0.1 to AOO 4.1.0 wouldn't be really helpful.


Most users couldn't care less but from the standpoint of a professional 
developer individual bi-sectable commits that address the different 
aspects of a problem are orders of magnitude better than their big-bang 
alternatives.



 Is there any scenario where we would need that switch to turn on
support for stlport?


A developer reusing the latest recipes from our snapshots page would 
fail with the latest trunk if the --without-stlport option was no longer 
recognized.


Also code bisection [1] is a very valuable tool in software engineering. 
When bisecting it is good when one doesn't have too many knobs to turn 
for each bisection step (such as if revdifferent option).


[1] http://en.wikipedia.org/wiki/Code_Bisection

Please learn about this powerful concept. It is another good reason to 
switch to git because it supports this facility wonderfully.


So the AOO evolution of the configure option was/is:
1) encourage the use of --without-stlport
2) identify and solve all issues on all target platforms
3) make --without-stlport the default
4) remove obsoleted code parts
5) remove --without-stlport being tolerated after it has become the 
default and it stopped being useful


The current trunk is now after step 4, but as described above tolerating 
the --without-stlport option is still useful.


Herbert

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Reporting a problem with the OpenOffice website

[Werner Janz]

Dear Sirs and Ladies

since the last Update of OpenOffice to 4.0.1 I`m faced with a lot of 
problems that make me really upset. Possibly I can`t use OpenOffice for 
my pruposes any more. So I`m not able to open my documents any more, 
because they are not shown on the symbollist, as they have be yet. How 
can I find my documents again and can open them???
I need an urgent answer. Otherwise I cant do my administration any more 
with OpenOffice.


Thank you very much for any advise.

Werner R. Janz
Facharzt Psychiatrie und Psychotherapie FMH
Gartenstadt 5, 4142 Münchenstein
Tel.: 061 413 03 03 Fax: 061 413 03 00


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: many many stlport issues...can anyone help

[Andre Fischer]

On 20.11.2013 08:33, Herbert Duerr wrote:


Please use the --without-stlport configure switch.

This option is the new default. Thanks to Jan for fixing configure.in. 
But you'd need to update to the newest trunk version to benefit from 
Jan's fix.




Is there any reason why we still need this option (be it default or 
not)?  Is there any scenario where we would need that switch to turn on 
support for stlport?


-Andre


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org