Re: Apache OpenOffice Building Guide

[Andrea Pescetti]

Guillermo Calzada wrote:

hello I've done autoconf.. but whit the configure i have  a problem...
iwhen a execute this line ./configure --with-dmake-url=
http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2
it gives me back a line telling me that it doesnt exists the directory
http://ooo.pastebin.ca/2389899


The error message says it all: either you are running configure in the 
wrong directory (you must execute it from within "main" too) or 
configure was not created by the previous step (it is created by 
autoconf). If the latter, then autoconf has failed and we need to see 
its output. Side note: there's no reason to build OpenOffice as root.


Regards,
  Andrea.

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

Re: Silent Installation on Installation Guide

[O.Felka]

Am 04.06.2013 22:49, schrieb Juergen Schmidt:

Am Dienstag, 4. Juni 2013 um 21:17 schrieb Alexandro Colorado:

I would like to clarify the silent installation process in AOO, the
Installation guide (which is for OOo) talks about running an MSI.

At the moment Windows versions are in an .exe file, no MSI to be found.

Q
​uestion ​
i
​s, do we still have silent installation process and if so? How to perform
such installation?


The silent installation is a Microsoft Installer (MSI) feature and not 
an OOo/AOo special.
If you call "Start -> Run -> 'msiexec /?'" you'll see all options of the 
MSI.


Regards,
Olaf



The exe us a self extracting zip file. When you look to the unpacked files you 
will see the msi

Juergen


Regards.​


--
Alexandro Colorado
Apache OpenOffice Contributor
http://es.openoffice.org









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

Re: [RELEASE]: new snapshot build based on trunk revision 1488886

[Jürgen Schmidt]

On 6/3/13 9:51 PM, Ariel Constenla-Haile wrote:
> On Mon, Jun 3, 2013 at 4:41 PM, Herbert Duerr  wrote:
>> The __builtin_isfinite() is used for for GCC as GCC's bug 14608 [1] prevents
>> the common isfinite() macro from working reliably. The builtin should work
>> according to the gcc documentation [2]: "GCC provides fpclassify, isfinite,
>> isinf_sign and isnormal built-ins used with __builtin_ prefixed."
>>
>> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608
>> [2] http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
>>
>> Looking through gcc's sources the builtin was introduced in [3] from
>> 2007-7-18 for gcc 4.3. I'm afraid we'll have to check for older gcc's there
>> and add another case for the ifdef GCC part.
>>
>> [3] http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=126725
>>
>> Considering that isfinite() was in the C99, C++99, SUSv3, etc standards for
>> almost fifteen years now it is amazing how much trouble such a two-bit
>> function can still introduce.
> 
> This CentOS has
> 
> g++ --version
> g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-54)
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I hope Herberts last fixes will solve this problem...


Anyway MacOS and Windows versions are uploaded and can be used. A SDK is
also available.

I am currently updating some languages and plan to start a further build
later today

- to solve the Linux problem
- and to include the first language builds (en_GB, es, nl, ru, sk).

fr, pt_BR, hu are in progress

Juergen

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

Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed

[Roberto Galoppini]

2013/6/4 Hans Zybura :
> Hi, comments inline...
>
> Crosspost to the api mailing list for a reason.
>
> Regards, Hans Zybura
>
>> -Original Message-
>> From: Oliver-Rainer Wittmann [mailto:orwittm...@googlemail.com]
>> Sent: Monday, June 03, 2013 10:47 AM
>> To: dev@openoffice.apache.org
>> Subject: Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
>> help needed
>>
>> Hi,
>>
>> small wrap-up at the top:
>> - nobody prefers to migrate extensions from AOO 3.4.x resp. OOo 3.x
>
> A couple of month ago there was a heated dispute about introducing 
> incompatible changes for extensions in the addons.xcu (for negligible 
> benefit). One of the arguments meant to silence the critics was: Well, it's 
> no problem because we have an update mechanism for extensions. I expressed 
> doubts if the update mechanism would work. Now it turns out I was wrong. I 
> shouldn't have worried about the update mechanism. Without migration, users 
> will have to find and reinstall all of their extensions anyway "by hand".
>
> The current update mechanism for extensions simply looks for a newer version 
> of the extension by use of a link provided by the extension developer 
> himself. We did that for our extension, but didn't have to make use of it 
> until now.
>
> OO developers decided not to take into account compatibility issues caused by 
> introducing incompatible changes in addons.xcu. OK, so we have to deal with 
> it. To prevent any trouble for our customers, we could very likely have 
> provided an automatic update, so that an end user wouldn't have noticed any 
> problem at all after a successful migration.
>
> Now OO developers are about to make it impossible for extension developers to 
> simply provide an automatic update before or after the migration to AOO 4.0. 
> Without migrating extensions, there is no automatic update path anymore.

AOOE beta-test site has already the update feature in place, we plan
to go live with the beta test sometimes next week, so that we'll have
a couple of weeks to test it extensively before AOO 4.0.

Hope this helps.

Roberto



> Great user experience! Great experience for extension developers and support 
> folks!
>
> I remember much talk about the "eco system of AOO" on this mailing list. Is 
> this what the talk was about?
>
>>
>> more comments inline.
>>
>> On 02.06.2013 13:17, Andrea Pescetti wrote:
>> > On 29/05/2013 Oliver-Rainer Wittmann wrote:
>> >> On 28.05.2013 18:23, Rob Weir wrote:
>> >>> Do we need to worry about the "messy" profiles that occurred from
>> >>> OOo
>> >>> 3.3.0 upgrades to AOO 3.4.0? That was when we saw spell checking
>> >>> breaking, missing dictionaries, and crashes. One of the nice things
>> >>> about a "clean start" with AOO 4.0 was that we avoid these kinds of
>> >>> problems.
>> >>  From my point of view AOO 3.4.x users which had problems due to a
>> >> "messy" profile and had solved these problems, can migrate their
>> >> profile to AOO 4.0. AOO 3.4.x users which does not had solved their
>> >> problems are able to suppress the migration of their existing profile
>> >> - see the corresponding FirstStartWizard page for the user profile
>> migration.
>> >
>> > I agree with Rob here that, since we had only a few widely reported
>> > bugs in OpenOffice 3.4.1 and one of them depended on the profile
>> > migration, we should be rather conservative.
>> >
>> > I agree it's better not to migrate extensions, since some of them
>> > might not work in OpenOffice 4 and their description.xml file in most
>> > cases will only state that they need "OpenOffice 3.0 or later".
>> >
>> >> Yes, an easy reset of the user profile would be great.
>> >
>> > This would be a very welcome improvement. Maybe technically this could
>> > invalidate the current profile and ask the user to restart OpenOffice,
>> > which would start on a clean profile. This would offer a good user
>> > experience (not optimal, since the optimal one would be triggered by a
>> > reinstallation too), and the right moment for the cleanup would be
>> > just after the code that checks if FirstStartWizard must be run and
>> > just before the profile is loaded and locked (which means that the
>> > "invalidate" bit must be set in a way that does not require profile
>> > access but probably a simple filesystem access... OK, I'll stop here!).
>> >
>> >> Thus, I assume that the risk of a defect or a regression is low when
>> >> solving issue 122398 and 122397 for AOO 4.0, except the issue which
>> >> would be "copied" from a "messy" user profile.
>> >
>> > This is a case to consider. So I would suggest to set the default
>> > answer to "Don't migrate" for extra safety, especially if we don't
>> > have an easy profile reset mechanism in place.
>>
>> I agree.
>> But it will cause translation effort - see screenshot of FirstStartWizard
>> migration page [1] String "...If you do not want to reuse any settings in
>> %PRODUCTNAME %PRODUCTVERSION, unmark the check box." will be
>> change to "

Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed

[Jürgen Schmidt]

On 6/4/13 11:28 PM, Hagar Delest wrote:
> Le 04/06/2013 22:47, Juergen Schmidt a écrit :
>> Well I am getting tired to repeat this again and again. Nobody should
>> expect that others do what's necessary, Just do it yourself -> it's a
>> community project.
> That's the problem. It seems there are different levels of understanding
> for the "community".
> 
> You tend to think that there is a huge community backing AOO and ready
> to jump into the code and other areas.

don't think that I am so stupid but we have enough things to do where
people without development skills can help and can do something.

And please don't generalize this, we talked with extension developers.
There are of course different groups of extension developers, with
different skill levels.

For me it's a difference if somebody who don't have the skills but shows
interest and ask the right questions or if somebody complain and request
that things get be done.

> I think that the reality is quite different: there is a huge base of
> users. But only users; wanting the application to work without having to
> put the hands inside.

I hope we always have a bigger user base than active community members.
Otherwise it would be a bad ratio but I agree that we could benefit fro
more volunteers in all areas.

> 
> 
> Let's face it: there are very few with dev skills; so you can't tell
> "just do it". What if we can't do it? Just shut up?
> If we shut up, nobody else will care about the users.

Nobody say that anybody should shut up.

We talk here about one specific case and not in general. Really anybody
interested could have started on the communication part.

Juergen


> 
> Hagar
> 
> -
> 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: The FreeBSD port is broken on trunk.

[Jürgen Schmidt]

On 6/5/13 5:09 AM, Pedro Giffuni wrote:
> Hi again;
> 
> On 04.06.2013 11:46, Pedro Giffuni wrote:
>> Hello;
>>
>> Just FYI, beyond the STL/TR1 issues ...
>>
>> It seems some of the recent changes broke configure for platforms
>> that report themselves as "amd64" instead of "x86_64":
>>
>> ...
>> checking for custom pack.lst... no
>> checking build system type... Invalid configuration
>> `amd64-portbld-freebsd9.1': machine `amd64-portbld' not recognized
>> configure: error: /bin/sh ./config.sub amd64-portbld-freebsd9.1 failed
>> ===>  Script "configure" failed unexpectedly.
>> ...
>>
>> There was a line in set_soenv.in that would do the adjustment but it
>> doesn't
>> seem to apply anymore.
>>
>>
> 
> After some further investigation it appears there is a similar problem
> in other ports so it is probably not an OpenOffice issue per-se.
> 
> Sorry for the noise.

no problem, for us it's better this way ;-)

> 
> I do have a workaround to keep building but still there are many
> pending issues to get AOO working on FreeBSD again :(.
> 

you should provide more details about the errors that Herbert can
support you. You can potentially benefit on FreeBSD from other changes
regarding clang.

Juergen

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

Re: The FreeBSD port is broken on trunk.

[Pedro Giffuni]

Hi again;

On 04.06.2013 11:46, Pedro Giffuni wrote:

Hello;

Just FYI, beyond the STL/TR1 issues ...

It seems some of the recent changes broke configure for platforms
that report themselves as "amd64" instead of "x86_64":

...
checking for custom pack.lst... no
checking build system type... Invalid configuration 
`amd64-portbld-freebsd9.1': machine `amd64-portbld' not recognized

configure: error: /bin/sh ./config.sub amd64-portbld-freebsd9.1 failed
===>  Script "configure" failed unexpectedly.
...

There was a line in set_soenv.in that would do the adjustment but it 
doesn't

seem to apply anymore.




After some further investigation it appears there is a similar problem
in other ports so it is probably not an OpenOffice issue per-se.

Sorry for the noise.

I do have a workaround to keep building but still there are many
pending issues to get AOO working on FreeBSD again :(.


Pedro.

Word boundary problem

[Badral S.]

Hi,
There is a bug with mongolian word boundary. MVS (180E) and Narrow No 
Break Space (202F) are handled as white spaces. These should not be so.
Narrow no break space is introduced by us to use for the mongolian 
suffix connection. Mongolian vowel separator is used to illustrate 
special last vowel formatting. (not separated from word!) There exist 
massive problems with spellchecker. See red points on the attachement.
I removed these characters from \main\linguistic\source\gciterator.cxx 
but I did'nt see any differences.

Is it handled by ICU library?

Badral


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

Re: Apache OpenOffice Building Guide

[Guillermo Calzada]

hello I've done autoconf.. but whit the configure i have  a problem...
iwhen a execute this line ./configure --with-dmake-url=
http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2

it gives me back a line telling me that it doesnt exists the directory

i added the problem to paste bin in the next link if you need it

http://ooo.pastebin.ca/2389899


Regards


2013/6/4 Kay Schenk 

> On Tue, Jun 4, 2013 at 2:57 PM, Guillermo Calzada  >wrote:
>
> > Hello looking i little bit more on my problem i realised that tehe
> scriptc
> > bootstrap doesnt exist... i just have bootstrap.1... i tried svn
> > updatebut i still dont have the script bootstrap...
> >
> > i send and image showing my directory aoo/main
> >
> > http://imagebin.org/index.php?mode=image&id=260251
> >
> >
> > Regards
> >
>
>
>
> You need to do "autoconf" and "configure" as in the Building Guide first.
> "bootstrap" is created during the configure process.
>
>
>
>
> You need to do
>
> >
> >
> > 2013/6/4 Andrea Pescetti 
> >
> > > Guillermo Calzada wrote:
> > >
> > >> Hello, I've been working on apache OpenOffice Building Guide, I've
> > dowload
> > >> the source, but i have problems whit the ./bootstrap...
> > >> the problem is that when i use it it gives me back a error that says
> > that
> > >> the ./bootstrap doesnt exist...
> > >>
> > >
> > > Follow the steps at
> > > http://wiki.openoffice.org/**wiki/Documentation/Building_**Guide_AOO<
> > http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO>
> > > (use the Preface and for the configure switches read the "Configuration
> > > and bootstrapping" section in the same page). Remember that ./bootstrap
> > > assumes that you execute it from within the directory named "main".
> > >
> > > If you receive errors in one of the previous steps, please post the
> error
> > > message here so we can help you.
> > >
> > > Regards,
> > >   Andrea.
> > >
> > >
> > >
> --**--**-
> > > To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> > dev-unsubscr...@openoffice.apache.org>
> > > For additional commands, e-mail: dev-h...@openoffice.apache.org
> > >
> > >
> >
>
>
>
> --
>
> 
> MzK
>
> "You can't believe one thing and do another.
>  What you believe and what you do are the same thing."
>  -- Leonard Peltier
>

svn cleanup

[Ivan Poot Diaz]

Hi all,


http://ooo.pastebin.ca/2389889

I want to know what is the reason for this error.

What could be the solution?

Start the download again or there will be a faster solution.

regards

Re: updates.openoffice.org

[Kay Schenk]

On Mon, Jun 3, 2013 at 5:11 AM, Oliver-Rainer Wittmann <
orwittm...@googlemail.com> wrote:

> Hi,
>
>
> On 03.06.2013 13:50, janI wrote:
>
>> On 3 June 2013 11:43, Oliver-Rainer Wittmann *
>> *wrote:
>>
>>  Hi,
>>>
>>> On 02.06.2013 16:43, janI wrote:
>>>
>>>  Hi.

 I have asked by my infra collegaues, to ensuere we (AOO) have consensus
 on
 how to handle updates.openoffice.org

 I nobody objects I will assume lazy consensus in 72 hours from now and

 1) create trunk/ooo-site/upates


>>> My understandings of the communication with infra is that
>>> ^/openoffice/updates-site/trunk/
>>> should be created for holding the needed application update data for AOO
>>> 4.0 and later.
>>>
>>> I am not sure, if my understanding is correct.
>>> Thus, please let us clarify it.
>>>
>>>
>>> Just for your information - the locations for the released versions are:
>>> - ^/openoffice/ooo-site/trunk/content/projects/update/aoo341/
>>> used by
>>> UpdateURL http://www.openoffice.org/projects/update/aoo341/check.***
>>> * 
>>> Update >> Update >for
>>> AOO 3.4.1
>>> - ^/openoffice/ooo-site/trunk/content/projects/update38/ used by
>>> UpdateURL 
>>> http://update38.services.**ope**noffice.org/**
>>> ProductUpdateService/check.Update>> services.openoffice.org/**ProductUpdateService/check.**Update>for
>>> AOO 3.4
>>> - ^/openoffice/ooo-site/trunk/content/projects/update36/ used by
>>> UpdateURL 
>>> http://update36.services.**ope**noffice.org/**
>>> ProductUpdateService/check.Update>> services.openoffice.org/**ProductUpdateService/check.**Update>for
>>> OOo 3.3
>>> - ^/openoffice/ooo-site/trunk/content/projects/update35/ used by
>>> UpdateURL 
>>> http://update35.services.**ope**noffice.org/**
>>> ProductUpdateService/check.Update>> services.openoffice.org/**ProductUpdateService/check.**Update>for
>>> OOo 3.2.1
>>> - ^/openoffice/ooo-site/trunk/content/projects/update34/ used by
>>> UpdateURL 
>>> http://update34.services.**ope**noffice.org/**
>>> ProductUpdateService/check.Update>> services.openoffice.org/**ProductUpdateService/check.**Update>for
>>> OOo 3.2
>>>
>>>
>> Using that we should make
>> ^/openoffice/ooo-site/trunk/**content/projects/update40/
>>   and have updates.o.o point at that.
>>
>
> We have already ^/openoffice/ooo-site/trunk/**content/projects/aoo40/ for
> current AOO 4.0 trunk builds - as stated in the communication with infra.
>
> I am currently very confused.
> Infra is telling "create ^/openoffice/updates-site/**trunk/"
> Jan is proposing "^/openoffice/trunk/ooo-site/**upates/"
> We already have "^/openoffice/ooo-site/trunk/**content/projects/aoo40/"
>
> If we can use whatever location for URL 
> https://updates.openoffice.**org/,
> why does we had a discussion on a new location?


Would  this work if:  https://updates.openoffice.org/
was directed to, and certificate applies to:

/openoffice/ooo-site/trunk/content/projects/

We still need to maintain the viability of the other update areas, don't we?

and, I think we originally had:

http://updates.services.openoffice.org

This caused problems long ago when we did a re-route of it. I'm not sure if
it still would or not.

@Oliver -- I'm not sure what you did to get some of this working.




>
>
>> Changing updates.o.o to point at something else is a one line statement so
>> no problem.
>>
>> Would it not be better if the AOO executable always called
>> https://updates.openoffice.**org?version=x
>>
>> That way the executable stays stable over versions, and we can have 1
>> server side script that checks the version.
>>
>>
> May be it would be better.
> But, somebody would be needed to implement such an adaption in the
> OpenOffice code and to implement the server side script.
>
> Best regards, Oliver.
>
>
>  rgds
>> jan I
>>
>> and have
>>
>>
>>
>>>
>>>
>>>   2) let https://updates.openoffice.org point to trunk/ooo-site/update
>>>


>>> Yes, https://updates.openoffice.org should point to the new application
>>> update data location.
>>>
>>>
>>> Best regards, Oliver.
>>>
>>> --**
>>> --**-
>>> To unsubscribe, e-mail: 
>>> dev-unsubscribe@openoffice.**a**pache.org

Re: Apache OpenOffice Building Guide

[Kay Schenk]

On Tue, Jun 4, 2013 at 2:57 PM, Guillermo Calzada wrote:

> Hello looking i little bit more on my problem i realised that tehe scriptc
> bootstrap doesnt exist... i just have bootstrap.1... i tried svn
> updatebut i still dont have the script bootstrap...
>
> i send and image showing my directory aoo/main
>
> http://imagebin.org/index.php?mode=image&id=260251
>
>
> Regards
>



You need to do "autoconf" and "configure" as in the Building Guide first.
"bootstrap" is created during the configure process.




You need to do

>
>
> 2013/6/4 Andrea Pescetti 
>
> > Guillermo Calzada wrote:
> >
> >> Hello, I've been working on apache OpenOffice Building Guide, I've
> dowload
> >> the source, but i have problems whit the ./bootstrap...
> >> the problem is that when i use it it gives me back a error that says
> that
> >> the ./bootstrap doesnt exist...
> >>
> >
> > Follow the steps at
> > http://wiki.openoffice.org/**wiki/Documentation/Building_**Guide_AOO<
> http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO>
> > (use the Preface and for the configure switches read the "Configuration
> > and bootstrapping" section in the same page). Remember that ./bootstrap
> > assumes that you execute it from within the directory named "main".
> >
> > If you receive errors in one of the previous steps, please post the error
> > message here so we can help you.
> >
> > Regards,
> >   Andrea.
> >
> >
> > --**--**-
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> dev-unsubscr...@openoffice.apache.org>
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
> >
>



-- 

MzK

"You can't believe one thing and do another.
 What you believe and what you do are the same thing."
 -- Leonard Peltier

Re: updates.openoffice.org

[janI]

On 5 June 2013 00:05, Rob Weir  wrote:

> On Tue, Jun 4, 2013 at 5:59 PM, janI  wrote:
> > On 4 June 2013 22:36, Andrea Pescetti  wrote:
> >
> >> On 03/06/2013 Rob Weir wrote:
> >>
> >>> I think the concern is this:
> >>> 1) We want SSL for 4.0.http://update.openoffice.**org<
> http://update.openoffice.org> is not HTTPS.
> >>>
> >>> 2) The URL https://ooo-site.openoffice.**apache.org<
> https://ooo-site.openoffice.apache.org> supports SSL, but is
> >>> not considered "long term stable".  The URL is an artifact of the CMS
> >>> 3) We're looking for a stable URL.  One could be
> >>> https://updates.openoffice.org**, but that requires an SSL cert for
> >>> *.openoffice.org.  But will that be supported in time for the AOO 4.0
> >>> release?
> >>> 4) Backup plan is updates.openoffice.apache.org, which could be
> >>> supported via SSL today, using the *.apache.org cert.  If we do that
> >>> we'd want to map that to its own CMS dir in SVN. so it can be updated
> >>> and published via the CMS.
> >>>
> >>
> >> This is mostly correct, except the fact (in #2 and #4) that the current
> >> certificates only support x.apache.org and not x.y.apache.org: so
> >> https://ooo-site.apache.org is what is in the sources right now (well,
> >> the last time I checked) and https://openoffice-updates.**apache.org<
> https://openoffice-updates.apache.org>(or something like that) should be
> used for the backup plan in #4.
> >>
> >
> > Hi
> >
> > I am confused, it seem we nearly all agree on
> > https://updates.openoffice.orgbut not on the directory.
> >
> > The order for the cert is being processed, when the cert arrives it needs
> > to be implemented on erebus-sll (our https: proxy), and we (infra) need
> to
> > do some updates on the aoo servers.
> >
> > In order to do this work, I need:
> >
> > 1) which url (e.g. https://updates.openoffice.org)
> > 2) should relate to which directory in svn.
> >
> > The last mails contains different proposal ranging from dont do it for
> 4.0
> > to different dirs, that is something I cannot implement.
> >
> > We can also decide to forget it for https:updates.*, but I need a single
> > decision to be able to implement it.
> >
>
> Is the cert already here?  Or do we have a few weeks to decide?  I'd
> say, don't let this decision get in the way of deploying the cert and
> enabling it for the website, wikis, forums, etc.   The update site
> doesn't need to be enabled until shortly before AOO 4.0 is released.
>
We have been promised a free cert, I just checked it is not yet in our
hands.

Wiki and other services with login, will be changed to https: to adhere to
asf/infra policy.
This will be done on infra initative, and the actual setup will be like
other servers in asf.

update.o.o can come later, but it will definitively save work if we do it
as one task. Of course if
the decision is to postpone after 4.0, it will be 2 tasks.



>
> And depending on when the cert arrives, we might not use it at all for
> 4.0 updates.  If it comes too late we'll just use an apache.org
> address.   So we're really waiting for Infra on this, not the other
> way around.  We need an estimate for when the cert will be purchased
> so we can decide whether or not it will be used for 4.0 updates.
>

As I understand it from the code, the end-user never sees this url, so why
not stick with apache.org ?

rgds
jan I.

>
> -Rob
>
>
> > rgds
> > jan I.
> >
> >>
> >> Regards,
> >>   Andrea.
> >>
> >>
> >>
> --**--**-
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> 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: updates.openoffice.org

[Rob Weir]

I should mention also that we have a BZ issue tracking this required
change.  It is categorized as a Release Blocker, so we don't forget
it:

https://issues.apache.org/ooo/show_bug.cgi?id=122444

-Rob

On Tue, Jun 4, 2013 at 6:05 PM, Rob Weir  wrote:
> On Tue, Jun 4, 2013 at 5:59 PM, janI  wrote:
>> On 4 June 2013 22:36, Andrea Pescetti  wrote:
>>
>>> On 03/06/2013 Rob Weir wrote:
>>>
 I think the concern is this:
 1) We want SSL for 
 4.0.http://update.openoffice.**org is not 
 HTTPS.

 2) The URL 
 https://ooo-site.openoffice.**apache.org
  supports SSL, but is
 not considered "long term stable".  The URL is an artifact of the CMS
 3) We're looking for a stable URL.  One could be
 https://updates.openoffice.org**, but that requires an SSL cert for
 *.openoffice.org.  But will that be supported in time for the AOO 4.0
 release?
 4) Backup plan is updates.openoffice.apache.org, which could be
 supported via SSL today, using the *.apache.org cert.  If we do that
 we'd want to map that to its own CMS dir in SVN. so it can be updated
 and published via the CMS.

>>>
>>> This is mostly correct, except the fact (in #2 and #4) that the current
>>> certificates only support x.apache.org and not x.y.apache.org: so
>>> https://ooo-site.apache.org is what is in the sources right now (well,
>>> the last time I checked) and 
>>> https://openoffice-updates.**apache.org(or
>>>  something like that) should be used for the backup plan in #4.
>>>
>>
>> Hi
>>
>> I am confused, it seem we nearly all agree on
>> https://updates.openoffice.orgbut not on the directory.
>>
>> The order for the cert is being processed, when the cert arrives it needs
>> to be implemented on erebus-sll (our https: proxy), and we (infra) need to
>> do some updates on the aoo servers.
>>
>> In order to do this work, I need:
>>
>> 1) which url (e.g. https://updates.openoffice.org)
>> 2) should relate to which directory in svn.
>>
>> The last mails contains different proposal ranging from dont do it for 4.0
>> to different dirs, that is something I cannot implement.
>>
>> We can also decide to forget it for https:updates.*, but I need a single
>> decision to be able to implement it.
>>
>
> Is the cert already here?  Or do we have a few weeks to decide?  I'd
> say, don't let this decision get in the way of deploying the cert and
> enabling it for the website, wikis, forums, etc.   The update site
> doesn't need to be enabled until shortly before AOO 4.0 is released.
>
> And depending on when the cert arrives, we might not use it at all for
> 4.0 updates.  If it comes too late we'll just use an apache.org
> address.   So we're really waiting for Infra on this, not the other
> way around.  We need an estimate for when the cert will be purchased
> so we can decide whether or not it will be used for 4.0 updates.
>
> -Rob
>
>
>> rgds
>> jan I.
>>
>>>
>>> Regards,
>>>   Andrea.
>>>
>>>
>>> --**--**-
>>> To unsubscribe, e-mail: 
>>> dev-unsubscribe@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: [VOTE] Logo selection for Apache OpenOffice 4.0

[Guenter Marxen]

--

HERE IS THE BALLOT:

My ranked preferences for the AOO 4.0 logo are:

1st Choice:

  - the gulls from Kevin
  - the fonts, font attributes and "text positions" of the old logo


2nd Choice: None of the above (our current logo)

3rd Choice: Samer Mansour (because of "text  position")

4th Choice: Kevin Grignon A (because of gulls)

5th Choice:



--
Grüße

Günter Marxen


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

Re: [VOTE][DISCUSS] Logo selection for Apache OpenOffice 4.0

[Dave Barton]

 Original Message  
From: Rob Weir 
To: dev@openoffice.apache.org , Dennis
Hamilton 
Date: Tue, 4 Jun 2013 08:45:32 -0400

> On Mon, Jun 3, 2013 at 9:39 PM, Dennis E. Hamilton  wrote:
>> I think if the "Apache" is made thicker by using Bold and a touch darker 
>> grey, it will work much better, at least as positioned in the Rottensteiner 
>> Stage 2 refinement.  It also gives "Apache" more (symbolic) weight without 
>> overpowering the "OpenOffice" part.
>>
>> I agree one wants to use the best of resampled PNG and regenerated SVG at 
>> the lower size.  Also, if the SVG has hints about the visually-intended size 
>> (at whatever pixel resolution), the fonts may be adjusted automatically to 
>> avoid excessive thinning at smaller presentation sizes.  Then there are the 
>> tricks needed when rasterization also becomes significant.
>>
> 
> Right.  And I hope that no one thinks that we're voting for pixels
> carved in marble.  We're voting on a design.  I'd expect ordinary
> technical adjustments to be made to suit the scale and medium of a
> particular use.  It should feel the same to a user, of course.  That's
> the advantage of having the vector source to a logo.  With the current
> logo it has been difficult to work with, since we only have the orb as
> a bitmap.
> 
> -Rob

Maybe I am missing something here (very possible), but I have the
current logo and a couple of variants in svg format. If required I would
be happy to upload them.

If someone would be kind enough to advise me how to create a public html
page ~bmcs (like https://people.apache.org/~arielch/), I will put all
the OOo & AOO related svg images I have collected there.

Dave

>>  - Dennis
>>
>> I don't have enough personal knowledge about SVG implementations and font 
>> hinting (although Adobe has information about it).  I do know that Knuth had 
>> to introduce anomorphic scaling into his fonts because the smaller ones 
>> would become visually too thin at the smaller point sizes if simply scaled 
>> geometrically.  It's a human vision thing.  He was producing images for 
>> production publishing systems and had a luxury of pixels; there was more 
>> involved that nudging pixel alignments.
>>
>> -Original Message-
>> From: Kay Schenk [mailto:kay.sch...@gmail.com]
>> Sent: Monday, June 3, 2013 04:54 PM
>> To: dev@openoffice.apache.org
>> Subject: Re: [VOTE][DISCUSS] Logo selection for Apache OpenOffice 4.0
>>
>> On Mon, Jun 3, 2013 at 3:35 PM, Rob Weir  wrote:
>>
>>> Staring a [VOTE][DISCUSS] thread parallel to the [VOTE] thread.
>>>
>>> On Mon, Jun 3, 2013 at 6:12 PM, Kay Schenk  wrote:
>>>
>>> .
>>> .
>>> .

 My comments with some very preliminary testing: the VERY LIGHT gray
 "Apache" in any form doesn't scale well going smaller.  The very thin
 letters also don't scale well going smaller.

>>>
>>> How did you scale the image?  By resizing the PNG file?  If so that
>>> probably doesn't give the optimal quality.
>>
>>
>> yes, this is what I did...
>>
>>
>>>  If we resize from the SVG
>>> source, and if the SVG references a vector font with "hinting", then
>>> it is possible that the text will be clearer at smaller sizes.  In
>>> theory that should help with the letter scaling.  Not sure about the
>>> light gray.
>>>
>>
>> Well maybe someone could  resize appropriately. Our current "web" logo is
>> only 200 x 100. I actually used 300 x ??? (kept the aspect ratio) and
>> things were not great on any of these with that very light gray
>> "Apache"...even slightly darker would help I think.
>>
>>
>>> -Rob


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

Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed

[Andrea Pescetti]

Hagar Delest wrote:

NB: has a communication been made to the extension authors asking them
to update their extension with the detailed changes to be made?
What is the idea for the moment? Hope that they will do that by
themselves because they certainly monitor the dev mailing list?


This is very important and it shows that indeed there are tasks that can 
only be done through cooperation.


Only a few people have clear ideas on what exactly is changing in 
OpenOffice 4 regarding extensions: so, those with this knowledge, please 
start a wiki page named "Upgrading your extensions for OpenOffice 4" or 
something like that.


Then, once that page is started, other community members can take over, 
point extensions authors to that page, we can ask to e-mail authors, we 
can refer users to that page, some extension authors will comment and 
improve the resource... but we need this to be started with something 
that is more descriptive than a list of Bugzilla issues. Developers 
needn't do everything, but the project needs them to start a 
documentation effort that can then be managed by others.


Regards,
  Andrea.

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

Re: updates.openoffice.org

[Rob Weir]

On Tue, Jun 4, 2013 at 5:59 PM, janI  wrote:
> On 4 June 2013 22:36, Andrea Pescetti  wrote:
>
>> On 03/06/2013 Rob Weir wrote:
>>
>>> I think the concern is this:
>>> 1) We want SSL for 
>>> 4.0.http://update.openoffice.**org is not 
>>> HTTPS.
>>>
>>> 2) The URL 
>>> https://ooo-site.openoffice.**apache.org
>>>  supports SSL, but is
>>> not considered "long term stable".  The URL is an artifact of the CMS
>>> 3) We're looking for a stable URL.  One could be
>>> https://updates.openoffice.org**, but that requires an SSL cert for
>>> *.openoffice.org.  But will that be supported in time for the AOO 4.0
>>> release?
>>> 4) Backup plan is updates.openoffice.apache.org, which could be
>>> supported via SSL today, using the *.apache.org cert.  If we do that
>>> we'd want to map that to its own CMS dir in SVN. so it can be updated
>>> and published via the CMS.
>>>
>>
>> This is mostly correct, except the fact (in #2 and #4) that the current
>> certificates only support x.apache.org and not x.y.apache.org: so
>> https://ooo-site.apache.org is what is in the sources right now (well,
>> the last time I checked) and 
>> https://openoffice-updates.**apache.org(or
>>  something like that) should be used for the backup plan in #4.
>>
>
> Hi
>
> I am confused, it seem we nearly all agree on
> https://updates.openoffice.orgbut not on the directory.
>
> The order for the cert is being processed, when the cert arrives it needs
> to be implemented on erebus-sll (our https: proxy), and we (infra) need to
> do some updates on the aoo servers.
>
> In order to do this work, I need:
>
> 1) which url (e.g. https://updates.openoffice.org)
> 2) should relate to which directory in svn.
>
> The last mails contains different proposal ranging from dont do it for 4.0
> to different dirs, that is something I cannot implement.
>
> We can also decide to forget it for https:updates.*, but I need a single
> decision to be able to implement it.
>

Is the cert already here?  Or do we have a few weeks to decide?  I'd
say, don't let this decision get in the way of deploying the cert and
enabling it for the website, wikis, forums, etc.   The update site
doesn't need to be enabled until shortly before AOO 4.0 is released.

And depending on when the cert arrives, we might not use it at all for
4.0 updates.  If it comes too late we'll just use an apache.org
address.   So we're really waiting for Infra on this, not the other
way around.  We need an estimate for when the cert will be purchased
so we can decide whether or not it will be used for 4.0 updates.

-Rob


> rgds
> jan I.
>
>>
>> Regards,
>>   Andrea.
>>
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> dev-unsubscribe@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: updates.openoffice.org

[janI]

On 4 June 2013 22:36, Andrea Pescetti  wrote:

> On 03/06/2013 Rob Weir wrote:
>
>> I think the concern is this:
>> 1) We want SSL for 
>> 4.0.http://update.openoffice.**org is not 
>> HTTPS.
>>
>> 2) The URL 
>> https://ooo-site.openoffice.**apache.org
>>  supports SSL, but is
>> not considered "long term stable".  The URL is an artifact of the CMS
>> 3) We're looking for a stable URL.  One could be
>> https://updates.openoffice.org**, but that requires an SSL cert for
>> *.openoffice.org.  But will that be supported in time for the AOO 4.0
>> release?
>> 4) Backup plan is updates.openoffice.apache.org, which could be
>> supported via SSL today, using the *.apache.org cert.  If we do that
>> we'd want to map that to its own CMS dir in SVN. so it can be updated
>> and published via the CMS.
>>
>
> This is mostly correct, except the fact (in #2 and #4) that the current
> certificates only support x.apache.org and not x.y.apache.org: so
> https://ooo-site.apache.org is what is in the sources right now (well,
> the last time I checked) and 
> https://openoffice-updates.**apache.org(or
>  something like that) should be used for the backup plan in #4.
>

Hi

I am confused, it seem we nearly all agree on
https://updates.openoffice.orgbut not on the directory.

The order for the cert is being processed, when the cert arrives it needs
to be implemented on erebus-sll (our https: proxy), and we (infra) need to
do some updates on the aoo servers.

In order to do this work, I need:

1) which url (e.g. https://updates.openoffice.org)
2) should relate to which directory in svn.

The last mails contains different proposal ranging from dont do it for 4.0
to different dirs, that is something I cannot implement.

We can also decide to forget it for https:updates.*, but I need a single
decision to be able to implement it.

rgds
jan I.

>
> Regards,
>   Andrea.
>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Apache OpenOffice Building Guide

[Guillermo Calzada]

Hello looking i little bit more on my problem i realised that tehe scriptc
bootstrap doesnt exist... i just have bootstrap.1... i tried svn
updatebut i still dont have the script bootstrap...

i send and image showing my directory aoo/main

http://imagebin.org/index.php?mode=image&id=260251


Regards


2013/6/4 Andrea Pescetti 

> Guillermo Calzada wrote:
>
>> Hello, I've been working on apache OpenOffice Building Guide, I've dowload
>> the source, but i have problems whit the ./bootstrap...
>> the problem is that when i use it it gives me back a error that says that
>> the ./bootstrap doesnt exist...
>>
>
> Follow the steps at
> http://wiki.openoffice.org/**wiki/Documentation/Building_**Guide_AOO
> (use the Preface and for the configure switches read the "Configuration
> and bootstrapping" section in the same page). Remember that ./bootstrap
> assumes that you execute it from within the directory named "main".
>
> If you receive errors in one of the previous steps, please post the error
> message here so we can help you.
>
> Regards,
>   Andrea.
>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Draw, make some changes to gradients

[Andrea Pescetti]

Forwarding Armin's and Regina's answers, below, to the original poster. 
bugreporter99: please follow 
http://mail-archives.apache.org/mod_mbox/openoffice-dev/ to read answers 
(or subscribe to this list, same link). Andrea


Regina Henschel wrote:

Hi Armin,

Armin Le Grand schrieb:

Hi Regina and bugreporter99,

a very interesting topic...
@bugreporter99: Which tasks did you commit for SVG? I did the SVG
import, so these should got to AOO probably, did they...?

Using multiple color steps in old gradients: A good idea, I already
thought about it. Problem is (as often) that we would need a ODF change
for it. Regina, could you think about something like that, please?


AOO has not yet implemented the  and
 (ODF 1.2 section 16.40.2 and 16.40.3). They allow
multiple stop-colors. The schema has
  
So in this gradient variant, it is already possible to use multiple
color steps (and some other nice stuff).

Therefore I think, that in a first step this should be implemented.

We

have start and end colors, in-between colors would have to be some value
pair of float [0..1] and color value...


The element svg:stop has the attributes
svg:offset, svg:stop-color, and svg:stop-opacity.
The offset is double (actual from 0..1) or percent, stop-color is
#rrggbb, and opacity is double (from 0..1). All is already in the standard.



Transparency: I thought myself about this; the current 100-0% setting to
blent the start/end color against black is really not very useful; it's
just handy to not change the color yourself. If adding an alpha value to
each color definition, these value entries in the UI could be reused. I
would guess users who know more modern apps think these values are
exactly that, sigh. Also needs a ODF change, though.


It is possible already using stop-opacity. I don't think, that we should
go the way to try to get additional attributes/subelements into
draw:gradient, but implement the two svg-gradients.



BoundRects of old gradients: This is old stuff some people thought about
16-20 years ago and of course not state of the art; it was a handy way
to draw these gradients at all (think 640kb systems) and got into ODF
later, sigh, but cannot be changed

SVG gradients: We already have these in the ODF spec, thus it will be
better to go forward and offer these for the current draw objects
directly., I think. Regina, what about ODF here and that it only allows
one of the SVG mapping modes, I think both should be possible.


Currently only objectBoundingBox is allowed. I think, that AOO should
have it implemented in a way, that both svg:gradientUnits methods are
possible. If an application supports a feature, it is easier to get it
into ODF. It can be done by using a gradientUnits in an own namespace
and later on, when it is in the ODF, map it to the official one on
reading. For such a namespace, discussion with Thorsten would be useful.



With all this, do not forget: More transparency makes all stuff more
fancy, BUT also makes printing more expensive (preparation, handling)
and also PDF export, especially PDF1/A stuff that does not allow
transparencies at all...


But that is needed already for proper rendering of svg graphics. So
hopefully many parts can be reused.

I'm not the right person to do it, but shouldn't be the way to use
modern graphic cards for the calculations?

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: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed

[Hagar Delest]

Le 04/06/2013 22:47, Juergen Schmidt a écrit :

Well I am getting tired to repeat this again and again. Nobody should expect that 
others do what's necessary, Just do it yourself -> it's a community project.

That's the problem. It seems there are different levels of understanding for the 
"community".

You tend to think that there is a huge community backing AOO and ready to jump 
into the code and other areas.
I think that the reality is quite different: there is a huge base of users. But 
only users; wanting the application to work without having to put the hands 
inside.


Let's face it: there are very few with dev skills; so you can't tell "just do 
it". What if we can't do it? Just shut up?
If we shut up, nobody else will care about the users.

Hagar

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

Re: Apache OpenOffice Building Guide

[Andrea Pescetti]

Guillermo Calzada wrote:

Hello, I've been working on apache OpenOffice Building Guide, I've dowload
the source, but i have problems whit the ./bootstrap...
the problem is that when i use it it gives me back a error that says that
the ./bootstrap doesnt exist...


Follow the steps at
http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO
(use the Preface and for the configure switches read the "Configuration 
and bootstrapping" section in the same page). Remember that ./bootstrap 
assumes that you execute it from within the directory named "main".


If you receive errors in one of the previous steps, please post the 
error message here so we can help you.


Regards,
  Andrea.

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

Re: Silent Installation on Installation Guide

[Juergen Schmidt]

Am Dienstag, 4. Juni 2013 um 21:17 schrieb Alexandro Colorado:
> I would like to clarify the silent installation process in AOO, the
> Installation guide (which is for OOo) talks about running an MSI.
>  
> At the moment Windows versions are in an .exe file, no MSI to be found.
>  
> Q
> ​uestion ​
> i
> ​s, do we still have silent installation process and if so? How to perform
> such installation?
>  
>  


The exe us a self extracting zip file. When you look to the unpacked files you 
will see the msi

Juergen  
>  
> Regards.​
>  
>  
> --  
> Alexandro Colorado
> Apache OpenOffice Contributor
> http://es.openoffice.org
>  
>  

Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed

[Juergen Schmidt]

Am Dienstag, 4. Juni 2013 um 22:00 schrieb Hagar Delest:
> Le 04/06/2013 20:27, Juergen Schmidt a écrit :
> > instead of complaining and requesting you could have joined the development 
> > and could have worked on one or more of your addressed issues. This is the 
> > way how open source works. The code is available and you can help to 
> > improve it.
>  
>  
> This is the standard reply of the devs community very often.
a reply to an extension developer  
> Please remember that OpenOffice is a rather specific project with a user base 
> made of basic users, not developers. This is not a toy for geeks who want to 
> implement cool things. So if the users are really disappointed because they 
> are not taken care of, they will just leave and go to LibreOffice for example.
>  
>  

you don't have  to repeat this, I know it and we normally take all kind of 
feedback serious. It's simply that we have many things to do...
>  
> Whatever the technical reason is, not taking into account the basic user 
> aspect is dangerous. There were ideas about having a transition phase but 
> nothing has really been made about that AFAIK.
some pro active collaboration of extension developers would be welcome. We 
don't simple ignore but we can't do everything.  
>   
>  
>  

>  
> If voices like ours dare say so against the dev community, it's because we 
> think that the users deserve a minimal care to keep them interested in the 
> product. I doubt they would ever engage in such a discussion. So please don't 
> forget about them, even if you don't hear their voices apart ours.
I agree and I expect the necessary collaboration from the extension developers. 
If they collaborate our users will be less affected.  
>  
> NB: has a communication been made to the extension authors asking them to 
> update their extension with the detailed changes to be made?
> What is the idea for the moment? Hope that they will do that by themselves 
> because they certainly monitor the dev mailing list?
>  
>  

I hope  it will be addressed appropriately. I am not responsible for everything 
;-)  
The facts are known and if somebody things it is not addressed yet just start 
working on it and don't wait that somebody else does it.
Well I am getting tired to repeat this again and again. Nobody should expect 
that others do what's necessary, Just do it yourself -> it's a community 
project.

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

Re: updates.openoffice.org

[Andrea Pescetti]

On 03/06/2013 Rob Weir wrote:

I think the concern is this:
1) We want SSL for 4.0.http://update.openoffice.org  is not HTTPS.
2) The URL https://ooo-site.openoffice.apache.org  supports SSL, but is
not considered "long term stable".  The URL is an artifact of the CMS
3) We're looking for a stable URL.  One could be
https://updates.openoffice.org, but that requires an SSL cert for
*.openoffice.org.  But will that be supported in time for the AOO 4.0
release?
4) Backup plan is updates.openoffice.apache.org, which could be
supported via SSL today, using the *.apache.org cert.  If we do that
we'd want to map that to its own CMS dir in SVN. so it can be updated
and published via the CMS.


This is mostly correct, except the fact (in #2 and #4) that the current 
certificates only support x.apache.org and not x.y.apache.org: so 
https://ooo-site.apache.org is what is in the sources right now (well, 
the last time I checked) and https://openoffice-updates.apache.org (or 
something like that) should be used for the backup plan in #4.


Regards,
  Andrea.

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

Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed

[Hagar Delest]

Le 04/06/2013 20:27, Juergen Schmidt a écrit :

instead of complaining and requesting you could have joined the development and 
could have worked on one or more of your addressed issues. This is the way how 
open source works. The code is available and you can help to improve  it.


This is the standard reply of the devs community very often.
Please remember that OpenOffice is a rather specific project with a user base 
made of basic users, not developers. This is not a toy for geeks who want to 
implement cool things. So if the users are really disappointed because they are 
not taken care of, they will just leave and go to LibreOffice for example.

Whatever the technical reason is, not taking into account the basic user aspect 
is dangerous. There were ideas about having a transition phase but nothing has 
really been made about that AFAIK.

If voices like ours dare say so against the dev community, it's because we 
think that the users deserve a minimal care to keep them interested in the 
product. I doubt they would ever engage in such a discussion. So please don't 
forget about them, even if you don't hear their voices apart ours.

NB: has a communication been made to the extension authors asking them to 
update their extension with the detailed changes to be made?
What is the idea for the moment? Hope that they will do that by themselves 
because they certainly monitor the dev mailing list?

Hagar

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

XPropertySetInfo implementation

[Rajath Shashidhara]

Hello everyone,

I was implementing XPropertySetInfo interface to return an object for it
when "getPropertySetInfo" command is executed.

I had a doubt about setting the attribute of Property as READONLY.

I have set Some properties like
"DateCreated","Size","IsFolder","IsDocument","ContentType","DateModified"
to READONLY.

Is it right?

Please provide feedback about code, so that I can revert back at this point
only if I have to. I'm coding "setPropertyValue" command also. If READONLY
type is requested for change, I'll have to add a IllegalAccessException to
Any[] that I return. So, that code also depends on this.
-- 
Rajath S,
M.Sc(Hons.) Physics,
Birla Institute of Technology and Science - Pilani,
Pilani

Re: integrated email client and calendar program

[Alexandro Colorado]

Back in the Old Old StarOffice 5.2 days, the office suite used to have a
File Manager, Calendar and Email client. OO API still has the mail bits on
the API for SMTP, Email handling libraries.

It would be interesting if there is a push to bring the PIM back and
rebuild the bits.

Base was developed using a more HTML-driven operation with more
concentration on the using the workspace as a dashboard.

In theory this way, it could be more mantainable to display and built
interfaces like the one of Calendars and Email.

We have talk with the people from KDE - Kolab which lately unveiled a
'Cloud service' which means we could develop a desktop client and they
could provide a service for remote support like Calendaring Free/Busy and
email hosting.

There still many things needed like handling a certification store
(currently AOO uses Mozilla's for their Digital signature). And update and
create some of the calendar bits specially managing things like Ical, vcal,
and other fileformats.


On Tue, Jun 4, 2013 at 2:10 PM, Mechtilde  wrote:

> Hello Alan,
>
> did you try Thunderbird?
>
> Regards
>
> Mechtilde
>
>
> Am 04.06.2013 20:30, schrieb Alan Kelley:
> > I would like to see an email client and calendar program integrated into
> > open office.
> >
> > kelle...@sprintmail.com
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
> >
>
>
>


-- 
Alexandro Colorado
Apache OpenOffice Contributor
http://es.openoffice.org

Silent Installation on Installation Guide

[Alexandro Colorado]

I would like to clarify the silent installation process in AOO, the
Installation guide (which is for OOo) talks about running an MSI.

At the moment Windows versions are in an .exe file, no MSI to be found.

Q
​uestion ​
i
​s, do we still have silent installation process and if so? How to perform
such installation?

Regards.​


-- 
Alexandro Colorado
Apache OpenOffice Contributor
http://es.openoffice.org

Re: integrated email client and calendar program

[Mechtilde]

Hello Alan,

did you try Thunderbird?

Regards

Mechtilde


Am 04.06.2013 20:30, schrieb Alan Kelley:
> I would like to see an email client and calendar program integrated into
> open office.
> 
> kelle...@sprintmail.com
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: [QA][Test Report] Weekly Status Update as of 20130531

[Kay Schenk]

On Mon, Jun 3, 2013 at 7:09 PM, Liu Ping  wrote:

> hi,Yuzhen Kay
>
>
> According final suggestion ,I create a shared query condition and limit
> Issue Type = DEFECT
>
> here's a link to the query and already upload QA weekly report in  wiki (
> http://wiki.openoffice.org/wiki/QA/Report/WeeklyReport/20130531)
>
>
> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=NeedConfirm_DEFECT&sharer_id=249289
>
>
Great! thanks...this is probably more what  we need.

I have been working on "confirmation" for some old reports -- older than
2010.

At this point, "confirmation" is really very difficult for many of them
given the old versions, etc. And many have to do with the user's own, very
specialized setup -- printers, etc.

Thanks for this new query.


>
> On Tue, Jun 4, 2013 at 6:18 AM, Kay Schenk  wrote:
>
> > On Mon, Jun 3, 2013 at 1:01 AM, Yuzhen Fan  wrote:
> >
> > > Thanks for the information, if we also eliminate "Patch" or "Task"
> items,
> > > the number will be smaller again, "2736". We will include this in
> report
> > > link in case anyone is interested.
> > >
> > > Regards,
> > > Yu Zhen
> > >
> >
> > good idea...I think this change will be better.
> >
> >
> >
> >
> > >
> > >
> > > On Mon, Jun 3, 2013 at 7:09 AM, Kay Schenk 
> wrote:
> > >
> > > > On Fri, May 31, 2013 at 5:50 AM, Yuzhen Fan 
> > wrote:
> > > >
> > > > > Hi All,
> > > > >
> > > > > We continue doing the AOO 4.0 Full Regression test this week, here
> is
> > > the
> > > > > weekly update (5/28 - 5/31), please find more detail statistics in
> > > wiki:
> > > > > http://wiki.openoffice.org/wiki/QA/Report/WeeklyReport/20130531
> > > > >
> > > > > *Test execution: *
> > > > > We have assigned 1732 text executions to about 20 volunteers(4 more
> > > this
> > > > > week), and completed about 43% in execution so far. 35% Mac test
> > > > executions
> > > > > have been done compared 0% last week! The target is to %100
> attempted
> > > > 1000
> > > > > test executions (741 so far) before June 6 providing all volunteers
> > > > > complete their assignments before that date.
> > > > >
> > > > > *Defect summary:*
> > > > > 1. 30 defects were opened and 19 defects were resolved this week,
> so
> > we
> > > > > have 11 (30-19) net new defects added in the backlog
> > > > > 2. Expose 2 Mac specific defects during quick testing on Mac 10.8
> > with
> > > > > 64-bit Java, Bug 122418 (fail to display color bar in color
> dropdown
> > > > list)
> > > > > need to set priority as it frustrates user to select color visibly
> > > > >
> > > > > *Issues & quality highlight:*
> > > > > 1. Encourage volunteers to continue executing test cases in
> TestLink
> > to
> > > > > achieve their assignment
> > > > > 2. Redhat is with risk as less testing done on them - inform/remind
> > > Linux
> > > > > test team assignees make progress on this platform
> > > > > 3. Do general use testing on Mac for assessment - no
> crash/hung/data
> > > > > lose/open file fail issues, but 2 Mac specific defects discovered,
> > need
> > > > set
> > > > > priority for the first one
> > > > > (1) Bug 122418 -[Mac]Fail to show color or display incorrectly in
> > Color
> > > > > Dropdown Menu --- Special on Mac
> > > > > (2) Bug 122420 -Can't Copy and Paste Hyperlink on Mac --- Special
> on
> > > Mac
> > > > > (3) Bug 122419 -The Second Slide can't apply footer/page number
> when
> > > > select
> > > > > "Don't show first slide" option -- Both on Mac and Win7
> > > > > (4) Bug 122421 -Shape remain group when change from ungroup to
> group
> > > > until
> > > > > double click shape -- Both on Mac and Win7
> > > > > 4. Critical defects are waiting for fix - need more Dev volunteers
> to
> > > > > involve
> > > > > 5. QAs are reminded to make sure to perform all test cases with
> > > > navigation
> > > > > and accelerators, and make sure to specify defect numbers in
> Testlink
> > > for
> > > > > failed test executions
> > > > > *
> > > > > Volunteer status: *
> > > > > 1. We have 4 more volunteers joining test executions, all are for
> Mac
> > > > > 2. No new volunteers(total 6 so far) on defect work, need more to
> > clean
> > > > > backlog of unconfirmed and resolved defects
> > > > > *
> > > > > Plan for next week:*
> > > > > 1. Prioritize critical defects and assign them to Dev volunteers
> > > > > 2. Confirm left ~100 critical defects which are not confirmed yet
> > > > > 3. Achieve the target (June 6) to complete 1000 test executions in
> > AOO
> > > > 4.0
> > > > > Full Regression test with the support from volunteers
> > > > >
> > > > > Thanks you all for effort this week, it is a great community here,
> if
> > > we
> > > > do
> > > > > a little bit more then we will get an awesome achievement. Thanks!!
> > > > >
> > > > > Regards,
> > > > > Yu Zhen
> > > > >
> > > >
> > > > Checking on the "Need to Confirm" entries, You might note that many
> of
> > > > these items are not actually "bug" reports but ideas or wish lists
> > > items. I
> > > > produced a sim

integrated email client and calendar program

[Alan Kelley]

I would like to see an email client and calendar program integrated into 
open office.


kelle...@sprintmail.com

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

Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed

[Juergen Schmidt]

Am Dienstag, 4. Juni 2013 um 19:26 schrieb Hans Zybura:
> Hi, comments inline...
> 
> Crosspost to the api mailing list for a reason.
> 
> Regards, Hans Zybura
> 
> > -Original Message-
> > From: Oliver-Rainer Wittmann [mailto:orwittm...@googlemail.com]
> > Sent: Monday, June 03, 2013 10:47 AM
> > To: dev@openoffice.apache.org
> > Subject: Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
> > help needed
> > 
> > Hi,
> > 
> > small wrap-up at the top:
> > - nobody prefers to migrate extensions from AOO 3.4.x resp. OOo 3.x
> > 
> 
> 
> A couple of month ago there was a heated dispute about introducing 
> incompatible changes for extensions in the addons.xcu (for negligible 
> benefit). One of the arguments meant to silence the critics was: Well, it's 
> no problem because we have an update mechanism for extensions. I expressed 
> doubts if the update mechanism would work. Now it turns out I was wrong. I 
> shouldn't have worried about the update mechanism. Without migration, users 
> will have to find and reinstall all of their extensions anyway "by hand".
> 
> The current update mechanism for extensions simply looks for a newer version 
> of the extension by use of a link provided by the extension developer 
> himself. We did that for our extension, but didn't have to make use of it 
> until now.
it is of course an open issue  that the update mechanism for extensions from 
the repo doesn't work. We have to address this with our friends from 
sourgeforge.
> 
> OO developers decided not to take into account compatibility issues caused by 
> introducing incompatible changes in addons.xcu. OK, so we have to deal with 
> it. To prevent any trouble for our customers, we could very likely have 
> provided an automatic update, so that an end user wouldn't have noticed any 
> problem at all after a successful migration.
the decision to do no migration of extension is based on the fact that we had 
problems with the user profile for AOO 3.4.x. We simply take this root to get a 
clean new profile for the future. 
> 
> Now OO developers are about to make it impossible for extension developers to 
> simply provide an automatic update before or after the migration to AOO 4.0. 
> Without migrating extensions, there is no automatic update path anymore.
this is not optimal but a one time shot only 
> 
> Great user experience! Great experience for extension developers and support 
> folks!
no it isn't but sometimes unpopular decision are useful to move forward. And a 
major release is the chance for such changes. 
> 
> 
> I remember much talk about the "eco system of AOO" on this mailing list. Is 
> this what the talk was about?
instead of complaining and requesting you could have joined the development and 
could have worked on one or more of your addressed issues. This is the way how 
open source works. The code is available and you can help to improve  it. 

Juergen
> 
> > 
> > more comments inline.
> > 
> > On 02.06.2013 13:17, Andrea Pescetti wrote:
> > > On 29/05/2013 Oliver-Rainer Wittmann wrote:
> > > > On 28.05.2013 18:23, Rob Weir wrote:
> > > > > Do we need to worry about the "messy" profiles that occurred from
> > > > > OOo
> > > > > 3.3.0 upgrades to AOO 3.4.0? That was when we saw spell checking
> > > > > breaking, missing dictionaries, and crashes. One of the nice things
> > > > > about a "clean start" with AOO 4.0 was that we avoid these kinds of
> > > > > problems.
> > > > > 
> > > > 
> > > > From my point of view AOO 3.4.x users which had problems due to a
> > > > "messy" profile and had solved these problems, can migrate their
> > > > profile to AOO 4.0. AOO 3.4.x users which does not had solved their
> > > > problems are able to suppress the migration of their existing profile
> > > > - see the corresponding FirstStartWizard page for the user profile
> > > > 
> > > 
> > > 
> > 
> > migration.
> > > 
> > > I agree with Rob here that, since we had only a few widely reported
> > > bugs in OpenOffice 3.4.1 and one of them depended on the profile
> > > migration, we should be rather conservative.
> > > 
> > > I agree it's better not to migrate extensions, since some of them
> > > might not work in OpenOffice 4 and their description.xml file in most
> > > cases will only state that they need "OpenOffice 3.0 or later".
> > > 
> > > > Yes, an easy reset of the user profile would be great.
> > > 
> > > This would be a very welcome improvement. Maybe technically this could
> > > invalidate the current profile and ask the user to restart OpenOffice,
> > > which would start on a clean profile. This would offer a good user
> > > experience (not optimal, since the optimal one would be triggered by a
> > > reinstallation too), and the right moment for the cleanup would be
> > > just after the code that checks if FirstStartWizard must be run and
> > > just before the profile is loaded and locked (which means that the
> > > "invalidate" bit must be set in a way that does not require profile
> > > 

Re: [VOTE][DISCUSS] Logo selection for Apache OpenOffice 4.0

[Rob Weir]

On Tue, Jun 4, 2013 at 1:47 PM, Dave Barton  wrote:
>  Original Message  
> From: Rob Weir 
> To: dev@openoffice.apache.org , Dennis
> Hamilton 
> Date: Tue, 4 Jun 2013 08:45:32 -0400
>
>> On Mon, Jun 3, 2013 at 9:39 PM, Dennis E. Hamilton  wrote:
>>> I think if the "Apache" is made thicker by using Bold and a touch darker 
>>> grey, it will work much better, at least as positioned in the Rottensteiner 
>>> Stage 2 refinement.  It also gives "Apache" more (symbolic) weight without 
>>> overpowering the "OpenOffice" part.
>>>
>>> I agree one wants to use the best of resampled PNG and regenerated SVG at 
>>> the lower size.  Also, if the SVG has hints about the visually-intended 
>>> size (at whatever pixel resolution), the fonts may be adjusted 
>>> automatically to avoid excessive thinning at smaller presentation sizes.  
>>> Then there are the tricks needed when rasterization also becomes 
>>> significant.
>>>
>>
>> Right.  And I hope that no one thinks that we're voting for pixels
>> carved in marble.  We're voting on a design.  I'd expect ordinary
>> technical adjustments to be made to suit the scale and medium of a
>> particular use.  It should feel the same to a user, of course.  That's
>> the advantage of having the vector source to a logo.  With the current
>> logo it has been difficult to work with, since we only have the orb as
>> a bitmap.
>>
>> -Rob
>
> Maybe I am missing something here (very possible), but I have the
> current logo and a couple of variants in svg format. If required I would
> be happy to upload them.
>
> If someone would be kind enough to advise me how to create a public html
> page ~bmcs (like https://people.apache.org/~arielch/), I will put all
> the OOo & AOO related svg images I have collected there.
>

Could you check what you have?  I have a version as well, where there
is an SVG, but the SVG merely points to a bitmap image for the orb and
gulls.  So not really pure SVG.  If you have something that is
entirely SVG, feel free to send it along and I can check it into SVN
for you.

-Rob

> Dave
>
>>>  - Dennis
>>>
>>> I don't have enough personal knowledge about SVG implementations and font 
>>> hinting (although Adobe has information about it).  I do know that Knuth 
>>> had to introduce anomorphic scaling into his fonts because the smaller ones 
>>> would become visually too thin at the smaller point sizes if simply scaled 
>>> geometrically.  It's a human vision thing.  He was producing images for 
>>> production publishing systems and had a luxury of pixels; there was more 
>>> involved that nudging pixel alignments.
>>>
>>> -Original Message-
>>> From: Kay Schenk [mailto:kay.sch...@gmail.com]
>>> Sent: Monday, June 3, 2013 04:54 PM
>>> To: dev@openoffice.apache.org
>>> Subject: Re: [VOTE][DISCUSS] Logo selection for Apache OpenOffice 4.0
>>>
>>> On Mon, Jun 3, 2013 at 3:35 PM, Rob Weir  wrote:
>>>
 Staring a [VOTE][DISCUSS] thread parallel to the [VOTE] thread.

 On Mon, Jun 3, 2013 at 6:12 PM, Kay Schenk  wrote:

 .
 .
 .
>
> My comments with some very preliminary testing: the VERY LIGHT gray
> "Apache" in any form doesn't scale well going smaller.  The very thin
> letters also don't scale well going smaller.
>

 How did you scale the image?  By resizing the PNG file?  If so that
 probably doesn't give the optimal quality.
>>>
>>>
>>> yes, this is what I did...
>>>
>>>
  If we resize from the SVG
 source, and if the SVG references a vector font with "hinting", then
 it is possible that the text will be clearer at smaller sizes.  In
 theory that should help with the letter scaling.  Not sure about the
 light gray.

>>>
>>> Well maybe someone could  resize appropriately. Our current "web" logo is
>>> only 200 x 100. I actually used 300 x ??? (kept the aspect ratio) and
>>> things were not great on any of these with that very light gray
>>> "Apache"...even slightly darker would help I think.
>>>
>>>
 -Rob
>
>
> -
> 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: Draw, make some changes to gradients

[Regina Henschel]

Hi Armin,

Armin Le Grand schrieb:

 Hi Regina and bugreporter99,

a very interesting topic...
@bugreporter99: Which tasks did you commit for SVG? I did the SVG
import, so these should got to AOO probably, did they...?

Using multiple color steps in old gradients: A good idea, I already
thought about it. Problem is (as often) that we would need a ODF change
for it. Regina, could you think about something like that, please?


AOO has not yet implemented the  and 
 (ODF 1.2 section 16.40.2 and 16.40.3). They allow 
multiple stop-colors. The schema has

  
So in this gradient variant, it is already possible to use multiple 
color steps (and some other nice stuff).


Therefore I think, that in a first step this should be implemented.

 We

have start and end colors, in-between colors would have to be some value
pair of float [0..1] and color value...


The element svg:stop has the attributes
svg:offset, svg:stop-color, and svg:stop-opacity.
The offset is double (actual from 0..1) or percent, stop-color is 
#rrggbb, and opacity is double (from 0..1). All is already in the standard.




Transparency: I thought myself about this; the current 100-0% setting to
blent the start/end color against black is really not very useful; it's
just handy to not change the color yourself. If adding an alpha value to
each color definition, these value entries in the UI could be reused. I
would guess users who know more modern apps think these values are
exactly that, sigh. Also needs a ODF change, though.


It is possible already using stop-opacity. I don't think, that we should 
go the way to try to get additional attributes/subelements into 
draw:gradient, but implement the two svg-gradients.




BoundRects of old gradients: This is old stuff some people thought about
16-20 years ago and of course not state of the art; it was a handy way
to draw these gradients at all (think 640kb systems) and got into ODF
later, sigh, but cannot be changed

SVG gradients: We already have these in the ODF spec, thus it will be
better to go forward and offer these for the current draw objects
directly., I think. Regina, what about ODF here and that it only allows
one of the SVG mapping modes, I think both should be possible.


Currently only objectBoundingBox is allowed. I think, that AOO should 
have it implemented in a way, that both svg:gradientUnits methods are 
possible. If an application supports a feature, it is easier to get it 
into ODF. It can be done by using a gradientUnits in an own namespace 
and later on, when it is in the ODF, map it to the official one on 
reading. For such a namespace, discussion with Thorsten would be useful.




With all this, do not forget: More transparency makes all stuff more
fancy, BUT also makes printing more expensive (preparation, handling)
and also PDF export, especially PDF1/A stuff that does not allow
transparencies at all...


But that is needed already for proper rendering of svg graphics. So 
hopefully many parts can be reused.


I'm not the right person to do it, but shouldn't be the way to use 
modern graphic cards for the calculations?


Kind regards
Regina

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

Re: [VOTE][DISCUSS] Logo selection for Apache OpenOffice 4.0

[Dave Barton]

 Original Message  
From: Rob Weir 
To: dev@openoffice.apache.org , Dennis
Hamilton 
Date: Tue, 4 Jun 2013 08:45:32 -0400

> On Mon, Jun 3, 2013 at 9:39 PM, Dennis E. Hamilton  wrote:
>> I think if the "Apache" is made thicker by using Bold and a touch darker 
>> grey, it will work much better, at least as positioned in the Rottensteiner 
>> Stage 2 refinement.  It also gives "Apache" more (symbolic) weight without 
>> overpowering the "OpenOffice" part.
>>
>> I agree one wants to use the best of resampled PNG and regenerated SVG at 
>> the lower size.  Also, if the SVG has hints about the visually-intended size 
>> (at whatever pixel resolution), the fonts may be adjusted automatically to 
>> avoid excessive thinning at smaller presentation sizes.  Then there are the 
>> tricks needed when rasterization also becomes significant.
>>
> 
> Right.  And I hope that no one thinks that we're voting for pixels
> carved in marble.  We're voting on a design.  I'd expect ordinary
> technical adjustments to be made to suit the scale and medium of a
> particular use.  It should feel the same to a user, of course.  That's
> the advantage of having the vector source to a logo.  With the current
> logo it has been difficult to work with, since we only have the orb as
> a bitmap.
> 
> -Rob

Maybe I am missing something here (very possible), but I have the
current logo and a couple of variants in svg format. If required I would
be happy to upload them.

If someone would be kind enough to advise me how to create a public html
page ~bmcs (like https://people.apache.org/~arielch/), I will put all
the OOo & AOO related svg images I have collected there.

Dave

>>  - Dennis
>>
>> I don't have enough personal knowledge about SVG implementations and font 
>> hinting (although Adobe has information about it).  I do know that Knuth had 
>> to introduce anomorphic scaling into his fonts because the smaller ones 
>> would become visually too thin at the smaller point sizes if simply scaled 
>> geometrically.  It's a human vision thing.  He was producing images for 
>> production publishing systems and had a luxury of pixels; there was more 
>> involved that nudging pixel alignments.
>>
>> -Original Message-
>> From: Kay Schenk [mailto:kay.sch...@gmail.com]
>> Sent: Monday, June 3, 2013 04:54 PM
>> To: dev@openoffice.apache.org
>> Subject: Re: [VOTE][DISCUSS] Logo selection for Apache OpenOffice 4.0
>>
>> On Mon, Jun 3, 2013 at 3:35 PM, Rob Weir  wrote:
>>
>>> Staring a [VOTE][DISCUSS] thread parallel to the [VOTE] thread.
>>>
>>> On Mon, Jun 3, 2013 at 6:12 PM, Kay Schenk  wrote:
>>>
>>> .
>>> .
>>> .

 My comments with some very preliminary testing: the VERY LIGHT gray
 "Apache" in any form doesn't scale well going smaller.  The very thin
 letters also don't scale well going smaller.

>>>
>>> How did you scale the image?  By resizing the PNG file?  If so that
>>> probably doesn't give the optimal quality.
>>
>>
>> yes, this is what I did...
>>
>>
>>>  If we resize from the SVG
>>> source, and if the SVG references a vector font with "hinting", then
>>> it is possible that the text will be clearer at smaller sizes.  In
>>> theory that should help with the letter scaling.  Not sure about the
>>> light gray.
>>>
>>
>> Well maybe someone could  resize appropriately. Our current "web" logo is
>> only 200 x 100. I actually used 300 x ??? (kept the aspect ratio) and
>> things were not great on any of these with that very light gray
>> "Apache"...even slightly darker would help I think.
>>
>>
>>> -Rob


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

RE: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed

[Hans Zybura]

Hi, comments inline...

Crosspost to the api mailing list for a reason.

Regards, Hans Zybura

> -Original Message-
> From: Oliver-Rainer Wittmann [mailto:orwittm...@googlemail.com]
> Sent: Monday, June 03, 2013 10:47 AM
> To: dev@openoffice.apache.org
> Subject: Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
> help needed
> 
> Hi,
> 
> small wrap-up at the top:
> - nobody prefers to migrate extensions from AOO 3.4.x resp. OOo 3.x

A couple of month ago there was a heated dispute about introducing incompatible 
changes for extensions in the addons.xcu (for negligible benefit). One of the 
arguments meant to silence the critics was: Well, it's no problem because we 
have an update mechanism for extensions. I expressed doubts if the update 
mechanism would work. Now it turns out I was wrong. I shouldn't have worried 
about the update mechanism. Without migration, users will have to find and 
reinstall all of their extensions anyway "by hand".

The current update mechanism for extensions simply looks for a newer version of 
the extension by use of a link provided by the extension developer himself. We 
did that for our extension, but didn't have to make use of it until now.

OO developers decided not to take into account compatibility issues caused by 
introducing incompatible changes in addons.xcu. OK, so we have to deal with it. 
To prevent any trouble for our customers, we could very likely have provided an 
automatic update, so that an end user wouldn't have noticed any problem at all 
after a successful migration.

Now OO developers are about to make it impossible for extension developers to 
simply provide an automatic update before or after the migration to AOO 4.0. 
Without migrating extensions, there is no automatic update path anymore.

Great user experience! Great experience for extension developers and support 
folks! 

I remember much talk about the "eco system of AOO" on this mailing list. Is 
this what the talk was about?

> 
> more comments inline.
> 
> On 02.06.2013 13:17, Andrea Pescetti wrote:
> > On 29/05/2013 Oliver-Rainer Wittmann wrote:
> >> On 28.05.2013 18:23, Rob Weir wrote:
> >>> Do we need to worry about the "messy" profiles that occurred from
> >>> OOo
> >>> 3.3.0 upgrades to AOO 3.4.0? That was when we saw spell checking
> >>> breaking, missing dictionaries, and crashes. One of the nice things
> >>> about a "clean start" with AOO 4.0 was that we avoid these kinds of
> >>> problems.
> >>  From my point of view AOO 3.4.x users which had problems due to a
> >> "messy" profile and had solved these problems, can migrate their
> >> profile to AOO 4.0. AOO 3.4.x users which does not had solved their
> >> problems are able to suppress the migration of their existing profile
> >> - see the corresponding FirstStartWizard page for the user profile
> migration.
> >
> > I agree with Rob here that, since we had only a few widely reported
> > bugs in OpenOffice 3.4.1 and one of them depended on the profile
> > migration, we should be rather conservative.
> >
> > I agree it's better not to migrate extensions, since some of them
> > might not work in OpenOffice 4 and their description.xml file in most
> > cases will only state that they need "OpenOffice 3.0 or later".
> >
> >> Yes, an easy reset of the user profile would be great.
> >
> > This would be a very welcome improvement. Maybe technically this could
> > invalidate the current profile and ask the user to restart OpenOffice,
> > which would start on a clean profile. This would offer a good user
> > experience (not optimal, since the optimal one would be triggered by a
> > reinstallation too), and the right moment for the cleanup would be
> > just after the code that checks if FirstStartWizard must be run and
> > just before the profile is loaded and locked (which means that the
> > "invalidate" bit must be set in a way that does not require profile
> > access but probably a simple filesystem access... OK, I'll stop here!).
> >
> >> Thus, I assume that the risk of a defect or a regression is low when
> >> solving issue 122398 and 122397 for AOO 4.0, except the issue which
> >> would be "copied" from a "messy" user profile.
> >
> > This is a case to consider. So I would suggest to set the default
> > answer to "Don't migrate" for extra safety, especially if we don't
> > have an easy profile reset mechanism in place.
> 
> I agree.
> But it will cause translation effort - see screenshot of FirstStartWizard
> migration page [1] String "...If you do not want to reuse any settings in
> %PRODUCTNAME %PRODUCTVERSION, unmark the check box." will be
> change to "...If you do want to reuse settings in %PRODUCTNAME
> %PRODUCTVERSION, mark the check box."
> 
> >
> >> Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed
> >> form (.zip file or .tar.gz file or ...) or let me know, if you want
> >> to try my builds.
> >
> > If you had a build available, it would be easier for the QA volunteers
> > to test.
> >
> 

Re: Draw, make some changes to gradients

[Armin Le Grand]

Hi Regina and bugreporter99,

a very interesting topic...
@bugreporter99: Which tasks did you commit for SVG? I did the SVG 
import, so these should got to AOO probably, did they...?


Using multiple color steps in old gradients: A good idea, I already 
thought about it. Problem is (as often) that we would need a ODF change 
for it. Regina, could you think about something like that, please? We 
have start and end colors, in-between colors would have to be some value 
pair of float [0..1] and color value...


Transparency: I thought myself about this; the current 100-0% setting to 
blent the start/end color against black is really not very useful; it's 
just handy to not change the color yourself. If adding an alpha value to 
each color definition, these value entries in the UI could be reused. I 
would guess users who know more modern apps think these values are 
exactly that, sigh. Also needs a ODF change, though.


BoundRects of old gradients: This is old stuff some people thought about 
16-20 years ago and of course not state of the art; it was a handy way 
to draw these gradients at all (think 640kb systems) and got into ODF 
later, sigh, but cannot be changed


SVG gradients: We already have these in the ODF spec, thus it will be 
better to go forward and offer these for the current draw objects 
directly., I think. Regina, what about ODF here and that it only allows 
one of the SVG mapping modes, I think both should be possible.


With all this, do not forget: More transparency makes all stuff more 
fancy, BUT also makes printing more expensive (preparation, handling) 
and also PDF export, especially PDF1/A stuff that does not allow 
transparencies at all...


Just my 2 cents...

On 04.06.2013 17:14, Regina Henschel wrote:

Hi,

bugreporte...@hushmail.com schrieb:

Many thanks for the answer Regina,

(thought I would be dopped to the spam folder ;) )


Coding is not the only way to make AOO better. For example there are
always people needed to test the product, whether the new features work
as intended and whether no regressions slipped in. Also usability is a
topic for non coder, and usability is not about a single design 
opinion,

but making tests like the icon test in LO.


actually I do report bugs, when I find some (in most cases svg stuff 
atm)



Currently the gradient is relative to the shape. Adjustments are done
with the Border property. With svg it is possible to define the 
gradient
relative to the parent of the shape and that is rendered correctly 
in AOO.


Looking at LO4.0.4 and AOO3.4.1 the gradients are not rendered 
correctly.

for example:
on AOO3.4.1 (can't tell about newer versions)


Please do not test with AOO 3.4.1. Rendering svg and rendering 
gradients have been reworked. Please use a current snapshot of AOO4.0


[..]

Transparency is an additional feature. You can already combine
transparency with solid color (I guess from the pdf-file, that you want
that), but you can also combine transparency with gradients. You need
not even use the same kind of gradient. It seems you have not yet
discovered the property 'Gradient' in the Transparency tab of the Area
dialog.


Yes, but if you look at the attachement
(https://www.libreoffice.org/bugzilla/attachment.cgi?id=79272) of the
bugreport I mentioned, it does not makde that much  sense (imo) to use
the percentage for the blackness. The transparency tab would just change
the WHOLE gradient transparency.


The transparency itself can be defined as gradient.

 But I'd like also to set the

transparency of each gradient color.


Transparency it a forth channel besides RGB. There exist nothing like 
a "transparency of a color". Each value of a pixel consists of four 
parts: Red, Green, Blue and transparency, each in the range of 0 to 255.


I do not really understand, which result you want to get. Your 
attachment shows some changes in UI, but do not explain, what the 
resulting gradient should look like.


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

The FreeBSD port is broken on trunk.

[Pedro Giffuni]

Hello;

Just FYI, beyond the STL/TR1 issues ...

It seems some of the recent changes broke configure for platforms
that report themselves as "amd64" instead of "x86_64":

...

checking for custom pack.lst... no
checking build system type... Invalid configuration `amd64-portbld-freebsd9.1': 
machine `amd64-portbld' not recognized
configure: error: /bin/sh ./config.sub amd64-portbld-freebsd9.1 failed
===>  Script "configure" failed
 unexpectedly.
...

There was a line in set_soenv.in that would do the adjustment but it doesn't
seem to apply anymore.


Regards,

Pedro.

Re: CMIS UCP getPropertyValues

[Rajath Shashidhara]

Hello Juergen,

I have tested the "getPropertyValues" command.
It works pretty nicely.

Please send me some pointers about my code so that I can improve.


On Tue, Jun 4, 2013 at 3:35 PM, Rajath Shashidhara <
rajaths.raja...@gmail.com> wrote:

> Is this the right way to convert an "any" object to properties array:
> pRequest = (Property[]) AnyConverter.toArray(arg0.Argument); ?
>
> because I need to convert the any object to sequence .
>
>
> On Tue, Jun 4, 2013 at 2:23 PM, Rajath Shashidhara <
> rajaths.raja...@gmail.com> wrote:
>
>> Hello Juergen,
>>
>> I think i'll have to more debugging. I'm facing some errors. I'll
>> continue once I complete it.
>>
>>
>> On Tue, Jun 4, 2013 at 1:50 PM, Jürgen Schmidt wrote:
>>
>>> On 6/4/13 10:01 AM, Rajath Shashidhara wrote:
>>> > Hello,
>>> >
>>> > I have successfully completed the implementation of
>>> "getPropertyValues" ucb
>>> > command for cmis ucp.
>>> >
>>> > My ContentProvider repo:
>>> > https://github.com/rajaths589/CMISContentProvider.git
>>> >
>>> > I wrote a client application to test my ucp:
>>> > https://github.com/rajaths589/CMISContentProviderTest.git
>>> >
>>> > What is my next Step?
>>> >
>>>
>>> sounds good, you make good progress. I think you can now move forward to
>>> take a closer look on the "open" command.
>>>
>>> You should document the steps on the wiki page. I can think of the
>>> following milestones
>>>
>>> 1. milestone
>>> was to setup a local Chemistry test server and get familiar with the
>>> Chemistry API. Use your own client to load a document from the CMIS
>>> store and open it manually with the Office.
>>> Status: done
>>>
>>> 2. milestone
>>> should be to use the internal office file open dialog and be able to
>>> browse in a CMIS file store and show the content of directories.
>>> Status: in progress
>>>
>>> 3. milestone
>>> be able to open and save files
>>> Status:
>>>
>>> 4. milestone
>>> creating, deleting, copy and moving content
>>>
>>> 5. milestone
>>> implement a options page to configure the user and connection
>>> information for several CMIS stores and make use of this information.
>>> Use internal password container... -> TBD
>>>
>>> 6. milestone
>>> Support https connections to CMIS stores using the internal certificate
>>> store and use the internal interaction handler ... -> TDB
>>>
>>> Juergen
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>
>>>
>>
>>
>> --
>> Rajath S,
>> M.Sc(Hons.) Physics,
>> Birla Institute of Technology and Science - Pilani,
>> Pilani
>>
>
>
>
> --
> Rajath S,
> M.Sc(Hons.) Physics,
> Birla Institute of Technology and Science - Pilani,
> Pilani
>



-- 
Rajath S,
M.Sc(Hons.) Physics,
Birla Institute of Technology and Science - Pilani,
Pilani

Re: Draw, make some changes to gradients

[Regina Henschel]

Hi,

bugreporte...@hushmail.com schrieb:

Many thanks for the answer Regina,

(thought I would be dopped to the spam folder ;) )


Coding is not the only way to make AOO better. For example there are
always people needed to test the product, whether the new features work
as intended and whether no regressions slipped in. Also usability is a
topic for non coder, and usability is not about a single design opinion,
but making tests like the icon test in LO.


actually I do report bugs, when I find some (in most cases svg stuff atm)


Currently the gradient is relative to the shape. Adjustments are done
with the Border property. With svg it is possible to define the gradient
relative to the parent of the shape and that is rendered correctly in AOO.


Looking at LO4.0.4 and AOO3.4.1 the gradients are not rendered correctly.
for example:
on AOO3.4.1 (can't tell about newer versions)


Please do not test with AOO 3.4.1. Rendering svg and rendering gradients 
have been reworked. Please use a current snapshot of AOO4.0


[..]

Transparency is an additional feature. You can already combine
transparency with solid color (I guess from the pdf-file, that you want
that), but you can also combine transparency with gradients. You need
not even use the same kind of gradient. It seems you have not yet
discovered the property 'Gradient' in the Transparency tab of the Area
dialog.


Yes, but if you look at the attachement
(https://www.libreoffice.org/bugzilla/attachment.cgi?id=79272) of the
bugreport I mentioned, it does not makde that much  sense (imo) to use
the percentage for the blackness. The transparency tab would just change
the WHOLE gradient transparency.


The transparency itself can be defined as gradient.

 But I'd like also to set the

transparency of each gradient color.


Transparency it a forth channel besides RGB. There exist nothing like a 
"transparency of a color". Each value of a pixel consists of four parts: 
Red, Green, Blue and transparency, each in the range of 0 to 255.


I do not really understand, which result you want to get. Your 
attachment shows some changes in UI, but do not explain, what the 
resulting gradient should look like.


Kind regards
Regina



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

Re: More information on C++ compiler in Build Guide

[Kay Schenk]

On Tue, Jun 4, 2013 at 12:52 AM, janI  wrote:

> On 4 June 2013 04:13, Alexandro Colorado  wrote:
>
> > IMO we should re-wire and update the specific information for builds and
> > distros. or go the other way and move this info into the original build
> > guide.
> > http://wiki.openoffice.org/wiki/Documentation/Building_Guide<
> > http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO>
> >
>

@Alexandro, I think this is a good suggestion.  More integration of
instructions...

> I think it would be best to:
> 1) have a wiki page, where we list our build setup (pr platform)
>- which sw is installed
>- which configure switches are used
>- any other things needed to setup an identical environment
>

Agreed, this is really a challenging task for most new developers. It
helped me to look at the info from our buildbots, but this didn't tell me
much about the existing installed software for a successful build.


> 2) I understand (maybe wrong), that the release build is different, so that
> should be documented like 1)
>

h...is this so? What are the differences and why would this be?


> 3) keep our building guides general (apart from small changes, I find them
> quite good)
>

Yes, they are. I really DID want to know about an esoteric bits with the
C++ compiler. What standard should it comply with etc. On my system, I have
a separate "stdlibs" that I could install but haven't. Do I need that,
etc.   I really have encountered some very odd C compiler behavior over the
course of my development experience, and I would like to help folks avoid
these frustrations.


> rgds
> jan I.
>

OK, some good idea here.  Hopefully, we can get some of these changes
accomplished soon.


> >
> > On Mon, Jun 3, 2013 at 7:05 PM, Kay Schenk  wrote:
> >
> > > Do we need some further explanation on C++ compiler capabilities in our
> > > Build Guide
> > >
> > > http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO
> > >
> > > given recent discussions on this list? One of the reasons I'm brining
> > this
> > > up is in my own experience, weird C issues can really drive you off the
> > > deep end.
> > >
> > > Thanks to anyone willing to edit this section.
> > >
> > > --
> > >
> > >
> >
> 
> > > MzK
> > >
> > > "You can't believe one thing and do another.
> > >  What you believe and what you do are the same thing."
> > >  -- Leonard Peltier
> > >
> >
> >
> >
> > --
> > Alexandro Colorado
> > Apache OpenOffice Contributor
> > http://es.openoffice.org
> >
>



-- 

MzK

"You can't believe one thing and do another.
 What you believe and what you do are the same thing."
 -- Leonard Peltier

Re: Draw, make some changes to gradients

[bugreporter99]

Many thanks for the answer Regina,

(thought I would be dopped to the spam folder ;) )

>Coding is not the only way to make AOO better. For example there are 
>always people needed to test the product, whether the new features
work 
>as intended and whether no regressions slipped in. Also usability is
a 
>topic for non coder, and usability is not about a single design
opinion, 
>but making tests like the icon test in LO.

actually I do report bugs, when I find some (in most cases svg stuff
atm)

>Currently the gradient is relative to the shape. Adjustments are done

>with the Border property. With svg it is possible to define the
gradient 
>relative to the parent of the shape and that is rendered correctly in
AOO.

 Looking at LO4.0.4 and AOO3.4.1 the gradients are not rendered
correctly.
for example:
on AOO3.4.1 (can't tell about newer versions)
  # the ellipsoid gradient (having more than 2 colors) is rendered
wrongly
  #also the hight of the ellipsoid gradient is rendered wrongly (cause
there is not option atm to set the hight/width of the gradient)
on  LO4.0.4
  #the same but seems like the issue with ellipsoid gradients with
more than 2 colors is maybe fixed in 4.1beta
>Transparency is an additional feature. You can already combine 
>transparency with solid color (I guess from the pdf-file, that you
want 
>that), but you can also combine transparency with gradients. You need

>not even use the same kind of gradient. It seems you have not yet 
>discovered the property 'Gradient' in the Transparency tab of the
Area 
>dialog.

Yes, but if you look at the attachement 
(https://www.libreoffice.org/bugzilla/attachment.cgi?id=79272) of the
bugreport I mentioned, it does not makde that much  sense (imo) to use
the percentage for the blackness. The transparency tab would just
change the WHOLE gradient transparency. But I'd like also to set the
transparency of each gradient color.
>We tend to make the draw stuff more like svg. Already now it is
possible 
>to use a svg-graphic; and its gradients are rendered nicely.

+2

>Area > Gradient is already the dialog page to edit gradients. What 
>editing feature do you miss on that page? But keep in mind, that
color 
>gradient and transparency are independent properties.

as described above that maybe should be changed a little (allowoing
also to change the transparency of each gradient color)

>Besides that, changes have to be compatible with ODF or find its way
in 
>the next version of ODF.

ODF needs to update faster so it can support the important/widely used
things of svg ;)

As you may noticed I'm a spoiled Inkscape user who just wants to
import some svg drawing into AOO/LO (at least some basic svg drawings
no animation or such things) :)

Kind regards bugreporter99.

On 03.06.2013 at 6:35 PM, "Regina Henschel"  wrote:Hi ???,

bugreporte...@hushmail.com schrieb:
> Dear Apache Open Office/Libre Office devs,
> the reason why I'm writing is, cause I can't code and want to make
OO
> better.

Coding is not the only way to make AOO better. For example there are 
always people needed to test the product, whether the new features
work 
as intended and whether no regressions slipped in. Also usability is a

topic for non coder, and usability is not about a single design
opinion, 
but making tests like the icon test in LO.

> Specially the way gradients in Draw works. At the moment the
gradients
> stuff is rudimentary.
> Well I guess little kids may have fun with this but you can't do
real
> work with that.
> So this HAS to be changed.
> At least the following things should be added:
> - possibility to use more than two colors for the gradient

+1

> - set the hight and width of the gradient

Currently the gradient is relative to the shape. Adjustments are done 
with the Border property. With svg it is possible to define the
gradient 
relative to the parent of the shape and that is rendered correctly in
AOO.

> - the percentage of the color should change the transparency and not
> the "blackness" of the color
>https://www.libreoffice.org/bugzilla/show_bug.cgi?id=64469

-1

Transparency is an additional feature. You can already combine 
transparency with solid color (I guess from the pdf-file, that you
want 
that), but you can also combine transparency with gradients. You need 
not even use the same kind of gradient. It seems you have not yet 
discovered the property 'Gradient' in the Transparency tab of the Area

dialog.

> Because this will break compatibillity with older Versions of OO I
> think there should be as much changes as
> possible to prevent having to do big changes in the future to the
> gradients stuff.
> So here is my suggestion to the GUI part (pdf file:
> http://temp-share.com/show/f3Ygit6Xn).
> The coding part is up to you cause that's out of my scope.

We tend to make the draw stuff more like svg. Already now it is
possible 
to use a svg-graphic; and its gradients are rendered nicely.

Besides that, changes have to be compatible with ODF or find 

Re: Apache OpenOffice Building Guide

[Albino B Neto]

2013/6/3 Guillermo Calzada :
> the problem is that when i use it it gives me back a error that says that
> the ./bootstrap doesnt exist...

Run the command: souce Linux.sh ??

Ex. if your distro x86_64:

source LinuxX86-64Env.Set.sh

   Albino

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

Re: [VOTE][DISCUSS] Logo selection for Apache OpenOffice 4.0

[Rob Weir]

On Mon, Jun 3, 2013 at 9:39 PM, Dennis E. Hamilton  wrote:
> I think if the "Apache" is made thicker by using Bold and a touch darker 
> grey, it will work much better, at least as positioned in the Rottensteiner 
> Stage 2 refinement.  It also gives "Apache" more (symbolic) weight without 
> overpowering the "OpenOffice" part.
>
> I agree one wants to use the best of resampled PNG and regenerated SVG at the 
> lower size.  Also, if the SVG has hints about the visually-intended size (at 
> whatever pixel resolution), the fonts may be adjusted automatically to avoid 
> excessive thinning at smaller presentation sizes.  Then there are the tricks 
> needed when rasterization also becomes significant.
>

Right.  And I hope that no one thinks that we're voting for pixels
carved in marble.  We're voting on a design.  I'd expect ordinary
technical adjustments to be made to suit the scale and medium of a
particular use.  It should feel the same to a user, of course.  That's
the advantage of having the vector source to a logo.  With the current
logo it has been difficult to work with, since we only have the orb as
a bitmap.

-Rob


>  - Dennis
>
> I don't have enough personal knowledge about SVG implementations and font 
> hinting (although Adobe has information about it).  I do know that Knuth had 
> to introduce anomorphic scaling into his fonts because the smaller ones would 
> become visually too thin at the smaller point sizes if simply scaled 
> geometrically.  It's a human vision thing.  He was producing images for 
> production publishing systems and had a luxury of pixels; there was more 
> involved that nudging pixel alignments.
>
> -Original Message-
> From: Kay Schenk [mailto:kay.sch...@gmail.com]
> Sent: Monday, June 3, 2013 04:54 PM
> To: dev@openoffice.apache.org
> Subject: Re: [VOTE][DISCUSS] Logo selection for Apache OpenOffice 4.0
>
> On Mon, Jun 3, 2013 at 3:35 PM, Rob Weir  wrote:
>
>> Staring a [VOTE][DISCUSS] thread parallel to the [VOTE] thread.
>>
>> On Mon, Jun 3, 2013 at 6:12 PM, Kay Schenk  wrote:
>>
>> .
>> .
>> .
>> >
>> > My comments with some very preliminary testing: the VERY LIGHT gray
>> > "Apache" in any form doesn't scale well going smaller.  The very thin
>> > letters also don't scale well going smaller.
>> >
>>
>> How did you scale the image?  By resizing the PNG file?  If so that
>> probably doesn't give the optimal quality.
>
>
> yes, this is what I did...
>
>
>>  If we resize from the SVG
>> source, and if the SVG references a vector font with "hinting", then
>> it is possible that the text will be clearer at smaller sizes.  In
>> theory that should help with the letter scaling.  Not sure about the
>> light gray.
>>
>
> Well maybe someone could  resize appropriately. Our current "web" logo is
> only 200 x 100. I actually used 300 x ??? (kept the aspect ratio) and
> things were not great on any of these with that very light gray
> "Apache"...even slightly darker would help I think.
>
>
>> -Rob
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>
>
>
> --
> 
> MzK
>
> "You can't believe one thing and do another.
>  What you believe and what you do are the same thing."
>  -- Leonard Peltier
>
>
> -
> 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: [VOTE] Logo selection for Apache OpenOffice 4.0

[Fernando Cassia]

Chris Rottensteiner
--

HERE IS THE BALLOT:

My ranked preferences for the AOO 4.0 logo are:

1st Choice: None of the above

2nd Choice: Logo-04

3rd Choice: Logo-34

4th Choice: Logo-36

5th Choice: Logo-26

-

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

Re: [VOTE] Logo selection for Apache OpenOffice 4.0

[Guy Waterval]

HERE IS THE BALLOT:

My ranked preferences for the AOO 4.0 logo are:

1st Choice: Logo-33

2nd Choice: Chris Rottensteiner

3rd Choice: Kevin Grignon A

4th Choice: "none of the above"

Re: CMIS UCP getPropertyValues

[Rajath Shashidhara]

Is this the right way to convert an "any" object to properties array:
pRequest = (Property[]) AnyConverter.toArray(arg0.Argument); ?

because I need to convert the any object to sequence .


On Tue, Jun 4, 2013 at 2:23 PM, Rajath Shashidhara <
rajaths.raja...@gmail.com> wrote:

> Hello Juergen,
>
> I think i'll have to more debugging. I'm facing some errors. I'll continue
> once I complete it.
>
>
> On Tue, Jun 4, 2013 at 1:50 PM, Jürgen Schmidt wrote:
>
>> On 6/4/13 10:01 AM, Rajath Shashidhara wrote:
>> > Hello,
>> >
>> > I have successfully completed the implementation of "getPropertyValues"
>> ucb
>> > command for cmis ucp.
>> >
>> > My ContentProvider repo:
>> > https://github.com/rajaths589/CMISContentProvider.git
>> >
>> > I wrote a client application to test my ucp:
>> > https://github.com/rajaths589/CMISContentProviderTest.git
>> >
>> > What is my next Step?
>> >
>>
>> sounds good, you make good progress. I think you can now move forward to
>> take a closer look on the "open" command.
>>
>> You should document the steps on the wiki page. I can think of the
>> following milestones
>>
>> 1. milestone
>> was to setup a local Chemistry test server and get familiar with the
>> Chemistry API. Use your own client to load a document from the CMIS
>> store and open it manually with the Office.
>> Status: done
>>
>> 2. milestone
>> should be to use the internal office file open dialog and be able to
>> browse in a CMIS file store and show the content of directories.
>> Status: in progress
>>
>> 3. milestone
>> be able to open and save files
>> Status:
>>
>> 4. milestone
>> creating, deleting, copy and moving content
>>
>> 5. milestone
>> implement a options page to configure the user and connection
>> information for several CMIS stores and make use of this information.
>> Use internal password container... -> TBD
>>
>> 6. milestone
>> Support https connections to CMIS stores using the internal certificate
>> store and use the internal interaction handler ... -> TDB
>>
>> Juergen
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>
>
>
> --
> Rajath S,
> M.Sc(Hons.) Physics,
> Birla Institute of Technology and Science - Pilani,
> Pilani
>



-- 
Rajath S,
M.Sc(Hons.) Physics,
Birla Institute of Technology and Science - Pilani,
Pilani

Re: glosary/terminology files in pootle

[janI]

On 3 June 2013 22:47, Claudio Filho  wrote:

> Hi
>
> 2013/6/2 janI :
> > On 2 June 2013 15:37, Andrea Pescetti  wrote:
> >> Adding terminology seems fine, of course. Requiring the review step is
> in
> >> principle OK for me too, but I wonder how it will work for languages
> where
> >> we don't have native speakers as committers: does it require that
> strings
> >> are explicitly marked as reviewed, or is it enough to ask volunteers to
> >> check the warnings generated by Pootle and then send a note to the l10n
> >> list saying that they have considered/ignored warnings appropriately?
> >>
> >
> > Asking volunteers to that would be a significant step in getting better
> > quality.
> >
> > The nice thing about pootle review is that it can be done be everyone. My
> > idea was to say something like "before moving po files back to svn, the
> > committer must run a pootle review, if there are errors/warnings not
> > explained by the translators on the mailing list, the files will not be
> > transferred".  I know it puts a little burden on the person who does the
> > transfer, but similar to receiving a code patch.
>
> I think that we have some mistake about the "review".
>

One thing is to generate all strings in the source lang, like en_US.
> When you do it, you can give any inconsistent problems, like use
> differents terms in differents parts doing the same thing. IMHO, the
> translation team from Sun did a incredible work about this interchange
> about UI and help contents.
>
This is a very important part, but not something we can have a program
doing, I think the  only way is having people look at a running AOO.


> Other step is to translate it for many langs, like StarOffice/OOo/AOO.
> A good practice is the use of glossary/terminology, giving to team a
> way to translate in the same way. Is possible to do this work without
> the glossary/terminology, but is possible that you will have a UI/help
> with differents terms for SAME thing, or some thing worse, like
> differents parts of UI with differents strings for the SAME thing.
>
That was what I thought of.

Providing a glossary is the first step (this can be generated based on
existing translations), having a glossary
also allows us to:
1) ask the translators to use pootle review
2) Check/enforce that the glossary is used, this can be done quite easy by
e.g. genLang.
3) Auto translate new strings (with fuzzy bit on), if in the glossary


> IMO, we are in this edge between the good and acceptable, and now, we
> can start a revision of all work. An example: pivot table, in pt_BR,
> was translated for "Assistente de dados" (data wizard?) instead
> "Tabela dinâmica". Before, all strings was consistent with the first
> option, that is good, but isn't the good choice of term. Today, (i
> believe that) all UI/help are aligned with the second term, that is
> more appropriate.
>
> When i did the translation, i found some original strings that could
> be written in other way or using other example. So, you can see 2
> review to do: one for original strings and other for evolve the
> translations.
>
agreed.

>
> In this time, if we implement the terminology practice, the new
> translations can do first the translation of glossary, and after load
> in pootle and provide for them translators the po file (to offline
> translations), giving a tool for a better and consistent translation.
> Who already did his translation, can review the work, giving a better
> quality for his translated AOO through revising the glossary and
> reflecting this work in the UI/help. Is possible too ignore this
> practice and do it freely. :-)
>
> Anyway, i think/suggest to start the process revision after 4.0[.1?].
> Today, only provide the resource and the use is free to all teams.
>
Yes, as soon as 4.0 is released, I intent to update genLang and get it
integrated.


>
> About the Pootle, i can help in admin it, if necessary (backup admin?). ;-)
>

thx for the offer. Pootle and the vm as such is being adminstrated by
infra, but in my opinion an extra project admin would be nice
@jsc as project admin, what is you view ?

rgds
jan I


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

Re: CMIS UCP getPropertyValues

[Rajath Shashidhara]

Hello Juergen,

I think i'll have to more debugging. I'm facing some errors. I'll continue
once I complete it.


On Tue, Jun 4, 2013 at 1:50 PM, Jürgen Schmidt wrote:

> On 6/4/13 10:01 AM, Rajath Shashidhara wrote:
> > Hello,
> >
> > I have successfully completed the implementation of "getPropertyValues"
> ucb
> > command for cmis ucp.
> >
> > My ContentProvider repo:
> > https://github.com/rajaths589/CMISContentProvider.git
> >
> > I wrote a client application to test my ucp:
> > https://github.com/rajaths589/CMISContentProviderTest.git
> >
> > What is my next Step?
> >
>
> sounds good, you make good progress. I think you can now move forward to
> take a closer look on the "open" command.
>
> You should document the steps on the wiki page. I can think of the
> following milestones
>
> 1. milestone
> was to setup a local Chemistry test server and get familiar with the
> Chemistry API. Use your own client to load a document from the CMIS
> store and open it manually with the Office.
> Status: done
>
> 2. milestone
> should be to use the internal office file open dialog and be able to
> browse in a CMIS file store and show the content of directories.
> Status: in progress
>
> 3. milestone
> be able to open and save files
> Status:
>
> 4. milestone
> creating, deleting, copy and moving content
>
> 5. milestone
> implement a options page to configure the user and connection
> information for several CMIS stores and make use of this information.
> Use internal password container... -> TBD
>
> 6. milestone
> Support https connections to CMIS stores using the internal certificate
> store and use the internal interaction handler ... -> TDB
>
> Juergen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
Rajath S,
M.Sc(Hons.) Physics,
Birla Institute of Technology and Science - Pilani,
Pilani

Re: CMIS UCP getPropertyValues

[Jürgen Schmidt]

On 6/4/13 10:01 AM, Rajath Shashidhara wrote:
> Hello,
> 
> I have successfully completed the implementation of "getPropertyValues" ucb
> command for cmis ucp.
> 
> My ContentProvider repo:
> https://github.com/rajaths589/CMISContentProvider.git
> 
> I wrote a client application to test my ucp:
> https://github.com/rajaths589/CMISContentProviderTest.git
> 
> What is my next Step?
> 

sounds good, you make good progress. I think you can now move forward to
take a closer look on the "open" command.

You should document the steps on the wiki page. I can think of the
following milestones

1. milestone
was to setup a local Chemistry test server and get familiar with the
Chemistry API. Use your own client to load a document from the CMIS
store and open it manually with the Office.
Status: done

2. milestone
should be to use the internal office file open dialog and be able to
browse in a CMIS file store and show the content of directories.
Status: in progress

3. milestone
be able to open and save files
Status:

4. milestone
creating, deleting, copy and moving content

5. milestone
implement a options page to configure the user and connection
information for several CMIS stores and make use of this information.
Use internal password container... -> TBD

6. milestone
Support https connections to CMIS stores using the internal certificate
store and use the internal interaction handler ... -> TDB

Juergen

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

CMIS UCP getPropertyValues

[Rajath Shashidhara]

Hello,

I have successfully completed the implementation of "getPropertyValues" ucb
command for cmis ucp.

My ContentProvider repo:
https://github.com/rajaths589/CMISContentProvider.git

I wrote a client application to test my ucp:
https://github.com/rajaths589/CMISContentProviderTest.git

What is my next Step?
-- 
Rajath S,
M.Sc(Hons.) Physics,
Birla Institute of Technology and Science - Pilani,
Pilani

Re: More information on C++ compiler in Build Guide

[janI]

On 4 June 2013 04:13, Alexandro Colorado  wrote:

> IMO we should re-wire and update the specific information for builds and
> distros. or go the other way and move this info into the original build
> guide.
> http://wiki.openoffice.org/wiki/Documentation/Building_Guide<
> http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO>
>
> I think it would be best to:
1) have a wiki page, where we list our build setup (pr platform)
   - which sw is installed
   - which configure switches are used
   - any other things needed to setup an identical environment
2) I understand (maybe wrong), that the release build is different, so that
should be documented like 1)
3) keep our building guides general (apart from small changes, I find them
quite good)

rgds
jan I.

>
> On Mon, Jun 3, 2013 at 7:05 PM, Kay Schenk  wrote:
>
> > Do we need some further explanation on C++ compiler capabilities in our
> > Build Guide
> >
> > http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO
> >
> > given recent discussions on this list? One of the reasons I'm brining
> this
> > up is in my own experience, weird C issues can really drive you off the
> > deep end.
> >
> > Thanks to anyone willing to edit this section.
> >
> > --
> >
> >
> 
> > MzK
> >
> > "You can't believe one thing and do another.
> >  What you believe and what you do are the same thing."
> >  -- Leonard Peltier
> >
>
>
>
> --
> Alexandro Colorado
> Apache OpenOffice Contributor
> http://es.openoffice.org
>

Re: HelpID on ToolBox needed?

[Andre Fischer]

On 03.06.2013 21:50, Regina Henschel wrote:

Hi,

in main\svx\source\sidebar\text\TextPropertyPanel.src
I notice, that the container ToolBox has a HelpID, but the commands 
are in ToolBoxItem. For example:

ToolBox TB_FONTCOLOR
{
  HelpID = HID_PPROPERTYPANEL_TEXT_TBX_FONT_COLOR;
  SVLook = TRUE ;
  Pos = MAP_APPFONT (X3, THIRD_LINE_Y) ;
  Size = MAP_APPFONT (TOOLBOX_ITEM_DD_WIDTH ,TOOLBOX_ITEM_HEIGHT ) ;
  TabStop = TRUE ;
  ItemList =
  {
ToolBoxItem
{
  Identifier = TBI_FONTCOLOR ;
  HelpID = HID_PPROPERTYPANEL_TEXT_TBI_FONT_COLOR;
  DropDown = TRUE ;
  Command = ".uno:Color";
};
  };
};

If I move the mouse around that field, I get no spot, where I see 
HID_PPROPERTYPANEL_TEXT_TBX_FONT_COLOR;

Therefore my question, is this HelpID for ToolBox needed at all?


Probably not.

- The toolbox items should cover the whole toolbox and therefore leave 
no space where HID_PPROPERTYPANEL_TEXT_TBX_FONT_COLOR would be active.


- It looks like the help text tied to the command URL (".uno.Color" in 
this case) orverrides the help text defined by the HelpID.  This would 
mean that we can drop HelpId on both levels (toolbox and item).


-Andre



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