Re: [user documentation] Requirements for a documentation project

[FR web forum]

Bonjour Guy,



>Become a committer is not my priority. I would only produce something
>helpful for endusers in my langage (I don't speak English)
I send again my proposition to join the french forum.
We have a specific forum dedicated to documentation:
http://forum.openoffice.org/fr/forum/forum37.html 
You are welcome to help us.

Re: [DISCUSS] ML Moderators

[Rob Weir]

While I remember, one other dependency to note. Whoever takes the lead
on security communications should also be added as a moderator on
ooo-announce.  This is so they can let their own security bulletin
posts through without delay.

-Rob

On Sep 12, 2012, at 6:51 PM, Rob Weir  wrote:

> On Sep 12, 2012, at 3:14 PM, Dave Fisher  wrote:
>
>> Hi,
>>
>> Here are the changes to moderation that will be requested shortly. If anyone 
>> else would like to be added please respond. I will create a JIRA issue for 
>> the changes this weekend.
>>
>> Please open another email thread to either discuss or propose where to 
>> document the moderators including the moderation documentation that Dennis 
>> has thoughtfully provided.
>>
>>> I think the action list and number of moderators needed is:
>>> ooo-commits - 2
>> + Peter Junge
>> + Louis Suárez-Potts 
>> - robweir
>>
>>> ooo-dev - 1
>> - robweir
>> + bmcs
>> + mayongl
>> + Ian Lynch 
>>
>>> ooo-issues - 2
>> + Peter Junge
>> + Louis Suárez-Potts 
>>
>>> ooo-notifications - 2
>> + Peter Junge
>> + Louis Suárez-Potts 
>>
>> ooo-qa
>> + Peter Junge
>> + Ji Yan 
>> + Louis Suárez-Potts 
>>
>>> ooo-private - 2
>> + Peter Junge
>> + Louis Suárez-Potts 
>>   Dennis will take care of these changes.
>>
>>> ooo-security - 2
>> - robweir
>>
>
> I never requested this. I asked for someone else to take the lead on
> the communications side of the Security team.  But I intend to
> continue with the work there I'm already involved in.
>
>
>>> ooo-users - 2
>> - robweir
>> - orcmid
>> + bmcs
>>
>>> ooo-users-fr - ?
>> - water...@sunrise.ch
>>
>>
>> Thanks & Regards,
>> Dave

Re: Clipart library

[Joost Andrae]

Hi Armin,

I can still reproduce the behavior described:

Open eg. 
http://openclipart.org/detail/172011/racing-helmet-by-gnokii-172011 in 
Firefox and drag the SVG file to the Gallery in AOO. On my system (Win7 
Pro 64 Bit) the resulting Gallery entry is a BMP file.



Joost wrote somewhere in this thread that SVG dropped to the gallery is
converted to bitmap formats. I checked this and it is not true.

When using a SVG from the gallery and svaing the document, I checked the
SVG embedded into the ODF format - it's exactly (byte by byte) the
original SVG I was dropping to the gallery.

Works as intended/expected.



Kind regards, Joost

Confusion between Macs and the rest of the world?

[Rory O'Farrell]

In most implementations of OpenOffice the configuration information is accessed 
through /Tools /Options. On a Mac, this information is accessible through 
Preferences.  This other path causes great confusion for Mac users when the 
problem advisor does not notice the use of the different operating system.  

Is there any reason why Macs use that path, and would it be possible to use the 
conventional /Tools /Options path on new builds, instead of, or as well as, the 
usual Preferences path on Macs?

-- 
Rory O'Farrell 

Re: Confusion between Macs and the rest of the world?

[Raphael Bircher]

Hi

Am 13.09.12 10:34, schrieb Rory O'Farrell:
> In most implementations of OpenOffice the configuration information is 
> accessed through /Tools /Options. On a Mac, this information is accessible 
> through Preferences.  This other path causes great confusion for Mac users 
> when the problem advisor does not notice the use of the different operating 
> system.  
>
> Is there any reason why Macs use that path, and would it be possible to use 
> the conventional /Tools /Options path on new builds, instead of, or as well 
> as, the usual Preferences path on Macs?
>
Mac has UI Guide Lines who are much stronger then on many other Systems.
One of this Guide line is to keep any settings in the Preferences. It's
on the same places on any Mac Programm. You confuse all experianced Mac
Users, if you change this.

So a big -100 from my side.

We should maybe create a Tutorial about the differences.

Greetings Raphael

Re: Confusion between Macs and the rest of the world?

[Rory O'Farrell]

On Thu, 13 Sep 2012 10:44:46 +0200
Raphael Bircher  wrote:

> Hi
> 
> Am 13.09.12 10:34, schrieb Rory O'Farrell:
> > In most implementations of OpenOffice the configuration information is 
> > accessed through /Tools /Options. On a Mac, this information is accessible 
> > through Preferences.  This other path causes great confusion for Mac users 
> > when the problem advisor does not notice the use of the different operating 
> > system.  
> >
> > Is there any reason why Macs use that path, and would it be possible to use 
> > the conventional /Tools /Options path on new builds, instead of, or as well 
> > as, the usual Preferences path on Macs?
> >
> Mac has UI Guide Lines who are much stronger then on many other Systems.
> One of this Guide line is to keep any settings in the Preferences. It's
> on the same places on any Mac Programm. You confuse all experianced Mac
> Users, if you change this.
> 
> So a big -100 from my side.
> 
> We should maybe create a Tutorial about the differences.
> 
> Greetings Raphael
> 
Thank you for the explanation, Raphael.  Would it be a good idea to provide _as 
well_ the standard /Tools /Options?  Then Mac users would have the best of both 
worlds!

-- 
Rory O'Farrell 

Re: Confusion between Macs and the rest of the world?

[Raphael Bircher]

Am 13.09.12 10:48, schrieb Rory O'Farrell:
> On Thu, 13 Sep 2012 10:44:46 +0200
> Raphael Bircher  wrote:
>
>> Hi
>>
>> Am 13.09.12 10:34, schrieb Rory O'Farrell:
>>> In most implementations of OpenOffice the configuration information is 
>>> accessed through /Tools /Options. On a Mac, this information is accessible 
>>> through Preferences.  This other path causes great confusion for Mac users 
>>> when the problem advisor does not notice the use of the different operating 
>>> system.  
>>>
>>> Is there any reason why Macs use that path, and would it be possible to use 
>>> the conventional /Tools /Options path on new builds, instead of, or as well 
>>> as, the usual Preferences path on Macs?
>>>
>> Mac has UI Guide Lines who are much stronger then on many other Systems.
>> One of this Guide line is to keep any settings in the Preferences. It's
>> on the same places on any Mac Programm. You confuse all experianced Mac
>> Users, if you change this.
>>
>> So a big -100 from my side.
>>
>> We should maybe create a Tutorial about the differences.
>>
>> Greetings Raphael
>>
> Thank you for the explanation, Raphael.  Would it be a good idea to provide 
> _as well_ the standard /Tools /Options?  Then Mac users would have the best 
> of both worlds!
>
If I'm not wrong you can do this with changing a option in the profile
Folder. But Enable both is not a good option for my point of view. And
this is not the only difference. There are also same different
shortcuts. A native Printing dialoge. A native Spellchecker, and same
other minor things. On Linux you have also same special features. In the
past we try to use OS Specific things, but avoid to have a compleet
different look and feel. A Thing that is not easy and get also harder in
future, I think.

Greetings Raphael

Re: Confusion between Macs and the rest of the world?

[Jürgen Schmidt]

On 9/13/12 10:48 AM, Rory O'Farrell wrote:
> On Thu, 13 Sep 2012 10:44:46 +0200
> Raphael Bircher  wrote:
> 
>> Hi
>>
>> Am 13.09.12 10:34, schrieb Rory O'Farrell:
>>> In most implementations of OpenOffice the configuration information is 
>>> accessed through /Tools /Options. On a Mac, this information is accessible 
>>> through Preferences.  This other path causes great confusion for Mac users 
>>> when the problem advisor does not notice the use of the different operating 
>>> system.  
>>>
>>> Is there any reason why Macs use that path, and would it be possible to use 
>>> the conventional /Tools /Options path on new builds, instead of, or as well 
>>> as, the usual Preferences path on Macs?
>>>
>> Mac has UI Guide Lines who are much stronger then on many other Systems.
>> One of this Guide line is to keep any settings in the Preferences. It's
>> on the same places on any Mac Programm. You confuse all experianced Mac
>> Users, if you change this.
>>
>> So a big -100 from my side.
>>
>> We should maybe create a Tutorial about the differences.
>>
>> Greetings Raphael
>>
> Thank you for the explanation, Raphael.  Would it be a good idea to provide 
> _as well_ the standard /Tools /Options?  Then Mac users would have the best 
> of both worlds!

I don't think so but we can do better to explain such useful
differentiation. Our goal should be to keep the UI simple or better to
make it more intuitive. We have many features that are not easy to find
yet and before we duplicate entries I would prefer to use the space for
something else.

In this specific case I think that Mac Users are aware of this
difference and of course would expect it where it is now. See for
example Firefox where it is done in the same way. We want to be a good
citizen on the Mac platform and will integrate in the best way we can.
There is still work to do.

Juergen

[QA Report] The table style fidelity enhancement in MSO Word 2007 format importing

[Jinlong Wu]

Hi All,

Here is the report of  table style fidelity enhancement in MSO Word 2007
format importing.

Please review.

1. Total test case number: 11
2. Total execution number: 11
3. Testing platforms
   - Windows XP
4. Pass rate: 100%
5. Bug analysis
Bug 120832 submitted and fixed.

Feature related bugs:
Bug 120832  some of
the font color is not correct

Re: Clipart library

[Ian Lynch]

On 12 September 2012 19:35, Regina Henschel  wrote:
> Hi Ian,
>
> Ian Lynch schrieb:
>
>> On 12 September 2012 17:52, Juergen Schmidt  wrote:
>>>
>>> Am Mittwoch, 12. September 2012 um 08:42 schrieb Armin Le Grand:

 Hi,

 just wanted to mention: I just tried it out, SVG graphics can now be
 part of the existing gallery due to the added SVG import support. D&D
 SVG into gallery theme works like a charm. Thus, all SVG cliparts can be
 added to whatever form of clipart extension/builtin.


>>>
>>> this is very nice, thanks for the info
>>
>>
>> I tried to drag an odg drawing into the gallery and it didn't work.
>> That seems strange. I expected odg would be the first filetype to be
>> accepted - am I missing something? (ok don't say a brain ;-) )
>>
>
> What do you try? I don't understand "drag an odg drawing into the gallery".

Hi Regina,

Sorry, I'll try to  give better information.

I'm using AOO 3.4.0 on Ubuntu 12.04.

I open up Writer and the gallery window. I go to a filer window and
find a .png or .svg file and drag it from the filer window to the
gallery window and the file images appear in the gallery. I open the
svg file in Draw and save it back as a .odg file and it appears in the
filer window. I then drag the .odg file from the filer window to the
gallery and it doesn't accept it. It seems strange to me that the
gallery accepts .png and .svg direct imports like this but not files
in the native format of AOO.

> If you have a Draw document opened and drag an object (oval, star, 3D-scene)
> from the edit window to the gallery, that should work without problems.
>
> Or do you try to drag an odg-document from your file manager to the gallery?
> I would not expect, that it works, because it is a complete document and not
> only the part, which contains a single object.

So why does it work with a .svg file? I have one that is complex with
a mixture of raster and vector components and it goes straight in.

If I wanted to take a selection of clip art from my filer into AOO
gallery, dragging and dropping the files from the filer window is
quick and easy as well as intuitive to the average user. In practice I
can see that this might be more likely with .svg, png and jpg files as
they are much more common than .odg. However, that then begs the
question of why we have a .odg format at all and don't just use .svg.
(Ok I know its a lot of work to do that but in principle).

It's a bit of a dilemma with using the OpenClipart library because
ideally all the images would be editable. The only real way to
guarantee that is to fully support svg. In terms of distribution
bandwidth, simple clip art in vector files take up very little space
so bundling a reasonable selection of arrows symbols etc in the main
distribution would be possible without increasing the size of the
download very much. Our average Windows user is going to be a lot
happier seeing at least some of these things on first installation
from the download.

My take on bloat is that if it makes things more complex to use or
slows down day to day operations it is a high priority to avoid it
because of its affect on the user experience. If it makes things
easier to use and only has the effect of a marginal increase in
download size it might well be that the benefits in encouraging wider
take up outweigh that specific disadvantage, especially as high speed
connections are more and more common. If a file of 135 Meg can be
downloaded OK, one of 140 or 150 is not going to make a significant
difference. For that reason I think we should provide more ready
usable clip art in the gallery and make it easy and intuitive as
possible to add more. If that principle is accepted the question then
is how much and in what format?

-- 
Ian

Ofqual Accredited IT Qualifications (The Schools ITQ)

www.theINGOTs.org +44 (0)1827 305940

The Learning Machine Limited, Reg Office, 36 Ashby Road, Tamworth,
Staffordshire, B79 8AQ. Reg No: 05560797, Registered in England and
Wales.

Re: Confusion between Macs and the rest of the world?

[Ian Lynch]

On 13 September 2012 10:23, Jürgen Schmidt  wrote:
> On 9/13/12 10:48 AM, Rory O'Farrell wrote:
>> On Thu, 13 Sep 2012 10:44:46 +0200
>> Raphael Bircher  wrote:
>>
>>> Hi
>>>
>>> Am 13.09.12 10:34, schrieb Rory O'Farrell:
 In most implementations of OpenOffice the configuration information is 
 accessed through /Tools /Options. On a Mac, this information is accessible 
 through Preferences.  This other path causes great confusion for Mac users 
 when the problem advisor does not notice the use of the different 
 operating system.

 Is there any reason why Macs use that path, and would it be possible to 
 use the conventional /Tools /Options path on new builds, instead of, or as 
 well as, the usual Preferences path on Macs?

>>> Mac has UI Guide Lines who are much stronger then on many other Systems.
>>> One of this Guide line is to keep any settings in the Preferences. It's
>>> on the same places on any Mac Programm. You confuse all experianced Mac
>>> Users, if you change this.
>>>
>>> So a big -100 from my side.
>>>
>>> We should maybe create a Tutorial about the differences.
>>>
>>> Greetings Raphael
>>>
>> Thank you for the explanation, Raphael.  Would it be a good idea to provide 
>> _as well_ the standard /Tools /Options?  Then Mac users would have the best 
>> of both worlds!
>
> I don't think so but we can do better to explain such useful
> differentiation. Our goal should be to keep the UI simple or better to
> make it more intuitive.

+1 - Already menus have so many options it is difficult to find things.
In principle better to reduce lists and replace with graphical
dialogue boxes with context sensitive help.

> We have many features that are not easy to find
> yet and before we duplicate entries I would prefer to use the space for
> something else.
>
> In this specific case I think that Mac Users are aware of this
> difference and of course would expect it where it is now. See for
> example Firefox where it is done in the same way. We want to be a good
> citizen on the Mac platform and will integrate in the best way we can.
> There is still work to do.
>
> Juergen

-- 
Ian

Ofqual Accredited IT Qualifications (The Schools ITQ)

www.theINGOTs.org +44 (0)1827 305940

The Learning Machine Limited, Reg Office, 36 Ashby Road, Tamworth,
Staffordshire, B79 8AQ. Reg No: 05560797, Registered in England and
Wales.

Re: Volunteers needed to pickup some tasks

[Dave Fisher]

On Sep 11, 2012, at 11:14 PM, Herbert Duerr wrote:

> On 08.09.2012 13:50, Rob Weir wrote:
>> I'm raising my focus a little in this project to look more into some
>> larger ecosystem opportunities. As part of this change in focus I'll
>> have less time to deal with day-to-day operational aspects of the
>> project. So I'd like to shed some responsibilities and I hope there
>> are volunteers able or willing to learn to pick up the following:
>> [...]
>> 3. Taking the lead on the AOO Security team, tracking vulnerability
>> reports, writing disclosure bulletins, coordinating with security
>> analysts and related open source projects.
> 
> Jian Fang Zhang and I volunteer to do this.

Thanks!

Rob recommends that you also moderate the ooo-announce list so that you can 
quickly let through any security bulletins that you write.

Shall I have you added as moderator to both ooo-announce and ooo-security?

Regards,
Dave


> 
> Herbert

Re: [DISCUSS] ML Moderators

[Dave Fisher]

On Sep 12, 2012, at 9:51 PM, Rob Weir wrote:

> On Sep 12, 2012, at 3:14 PM, Dave Fisher  wrote:
> 
>> Hi,
>> 
>> Here are the changes to moderation that will be requested shortly. If anyone 
>> else would like to be added please respond. I will create a JIRA issue for 
>> the changes this weekend.
>> 
>> Please open another email thread to either discuss or propose where to 
>> document the moderators including the moderation documentation that Dennis 
>> has thoughtfully provided.
>> 
>>> I think the action list and number of moderators needed is:
>>> ooo-commits - 2
>> + Peter Junge
>> + Louis Suárez-Potts 
>> - robweir
>> 
>>> ooo-dev - 1
>> - robweir
>> + bmcs
>> + mayongl
>> + Ian Lynch 
>> 
>>> ooo-issues - 2
>> + Peter Junge
>> + Louis Suárez-Potts 
>> 
>>> ooo-notifications - 2
>> + Peter Junge
>> + Louis Suárez-Potts 
>> 
>> ooo-qa
>> + Peter Junge
>> + Ji Yan 
>> + Louis Suárez-Potts 
>> 
>>> ooo-private - 2
>> + Peter Junge
>> + Louis Suárez-Potts 
>>   Dennis will take care of these changes.
>> 
>>> ooo-security - 2
>> - robweir
>> 
> 
> I never requested this. I asked for someone else to take the lead on
> the communications side of the Security team.  But I intend to
> continue with the work there I'm already involved in.

ACK. My apologies. I've asked Herbert if he would like to be added to 
ooo-announce and ooo-security.

> 
> 
>>> ooo-users - 2
>> - robweir
>> - orcmid
>> + bmcs
>> 
>>> ooo-users-fr - ?
>> - water...@sunrise.ch

Does anyone volunteer to moderate the low volume ooo-users-fr ML?

Regards,
Dave

>> 
>> 
>> Thanks & Regards,
>> Dave

Re: [QA CALLFORREV​IEW] [testuno]C​heck paper format in SW via UNO API

[Xiao Ting Xiao]

attach the patch, use uno to test page format, include

1. page's width/height, orientation, margin
2. page's background, include back color and back graphic
3. page's header/footer settings, such as margin, spacing, height,
border, background

also include 3 methods in SWUtil.java

one update in sw/DocumentTest.java to apply latest version of
prepareData() method in Testspace.java

Please help reivew, it has been submitted with bug 120784,
https://issues.apache.org/ooo/show_bug.cgi?id=120784

On Fri, Aug 31, 2012 at 6:54 PM, Xiao Ting Xiao  wrote:

> Hi all,
>
> One patch for UNO automation test script has been submitted with *Bug
> 120784,
> https://issues.apache.org/ooo/show_bug.cgi?id=120784
>
> This patch include:
> paper's width, height
> paper's orientation
> paper's margin
> paper's background
>
> Please help review.
>

Re: Pootle projects

[FR web forum]

Bonjour,



>> The 3.5.x project is necessary to cleanup the translation.

>the jira issue for a new 3.5 project will be created if we agree on my
>proposed approach.

What's up about this?

Re: Pootle projects

[Jürgen Schmidt]

On 9/13/12 3:10 PM, FR web forum wrote:
> Bonjour,
> 
> 
> 
>>> The 3.5.x project is necessary to cleanup the translation.
> 
>> the jira issue for a new 3.5 project will be created if we agree on my
>> proposed approach.
> 
> What's up about this?
> 

I think we have first to fix the general Pootle problem and I will try
to catch up on this. But if anybody else feel able to help please do so.

Juergen

[DISCUSS]Actually attach a list style to the "Numbering #" paragraph styles

[RGB ES]

On Writer, you have paragraph styles and numbering styles, and it is
possible to call the second kind of styles from the first ones in order to
build a series of paragraphs with automatic numbering or bullets.

On its default configuration, Writer offers a series of paragraph styles
called "Numbering #", with # going from 1 to 10 (and "Start", "Cont." and
"End" variants of all of them), as well as paragraph styles called "List
#".

The problem is that those paragraph styles cannot be used out of the box to
make numbered lists or bullets because they do not have a numbering style
associated: the "Numbering style" on the "Outline & Numbering" tab inside
the style properties is set to "None" on all those styles.

On the current form, those paragraph styles do not fulfil any purpose and
every now  and then (not very often, that's true) we have on the forums
confused users that do not understand why those "Numbering" styles do not
do numbering at all.

I think the default built-in template should be changed to actually
associate numbering styles to those paragraph styles.

See this old request on bugzilla

Bug 42280 - Numbering and List paragraph styles should have numbering style
by default

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

What do you think?

Regards
Ricardo

Re: Problems with axial gradient and low color steps

[Regina Henschel]

Hi Armin,

comments inline.

Armin Le Grand schrieb:

Hi Regina,

On 08.09.2012 21:27, Regina Henschel wrote:

Hi Armin,

Armin Le Grand schrieb:

 Hi Regina,

On 06.09.2012 21:35, Regina Henschel wrote:

Hi all,

I see a lot of problems with axial gradients, but I'm not sure about
the
desired behavior.
Please have look at attachment
https://issues.apache.org/ooo/attachment.cgi?id=79324 in bug
https://issues.apache.org/ooo/show_bug.cgi?id=120604

Problem (1): How many color steps has an axial gradient, if the user
set
it to n steps in the UI? Old versions (SO5.2 to at least OOo2.4.3) make
it in n steps, with n/2 steps blending color "up" and n/2 steps
blending
color "down". Around OOo3.2.1 this behavior was changed so that (n-1)
steps "up", 1 step in the middle and (n-1) steps down. In AOO we have
now (n-1) steps "up" and (n-1) steps "down". The ODF does not specify
it.


How many stripes should the shape show, if the user sets the step count
to 5 ?
5 -> old behavior, does not fit at all
8 -> behavior in 3.4.1 and 3.5
9 -> behavior in 3.2.1, only one middle strip
10 -> I would prefer this; as in 3.2.1, but with double middle strip


I agree. I first thought about 9, but 10 is the exactly once mirrored
behaviour of 'linear'. Do we have a task for it?



I have written https://issues.apache.org/ooo/show_bug.cgi?id=120604.






Problem (2): What colors should the steps have? In the old version the
colors for "up" and "down" where different, what I think has been a
bug.


Yes. Also the step count was wrongly interpreted. There are numerous
errors in the old, VCL-based gradient painters.


In AOO 3.4.1 version neither the start not the end color is used, only
values between.


Start and end color should be used (if visible). In the Yellow/Green
example this seems to be okay.


Compare it with pure color green and pure color yellow and compare it
with a linear gradient with green -> yellow and linear gradient with
yellow -> green.

The linear gradient includes the start color and excludes the end color.
(I think that it would be better the other way round, because the start
color can be included via border. But that is a different problem.)

The axial gradient has neither start nor end color.


I see this both as errors. Start and end color should always be used. Do
we have tasks for this?



I think, that it can be handled together in 
https://issues.apache.org/ooo/show_bug.cgi?id=120604, because it is all 
in the same file.








Problem (3): The old gradients are still used for presentation mode,


AFAIK presentation has its own gradient rendering, targeted at
system-specific canvases. If redoing this, it sould use the primitives
directly (one day). It's an export.


converting to bitmap,


Should use primitives nowadays. If not, should be changed to do so.


Indeed, that is fixed in AOO3.5. It is correct for export to png and jpg
too in AOO3.5.

Copy and Save as "GDI metafile" is better in AOO3.5 than in AOO3.4.1.
The gradient is the same as for the shape and the gradient rotates
together with the shape, as expected for a picture. But 'Break' and
'Convert to bitmap' are wrong. 'Convert to bitmap' looses the rotation
which comes from the shape rotation and 'Break' looses the step count in
addition. But that is not specific for axial gradient.




export to pdf


Yes, is based on and 'paints' metafiles (but not with the VCL
mechanisms). It's an export and should be changed to primitive usage one
day.


Mh. If I export it to pdf using my build with my changes in
OutputDevice::ImplDrawLinearGradient, I can see exact this changes.


Okay, so export to metafile uses OutputDevice::ImplDrawLinearGradient.




and flash.


Not sure about this, also an export.


I think, that needs to be
fixed. I have looked around, and think, that it is in
OutputDevice::ImplDrawLinearGradient in
\main\vcl\source\gdi\outdev4.cxx. Is that right? If yes, are other
places effected as well? Should it be fixed or is someone working on a
more general solution?


It *could* be fixed there if really used. Have You tried to set breaks
(pr fprintfs) to check this? Most usages should not use it.


No. I have changed the colors and steps in
OutputDevice::ImplDrawLinearGradient and can see those changes using the
resulting build.


Good.



If it is used, it could be made to work using temp primitives internally
to ensure equal rendering.


As far as I have tested, OutputDevice::ImplDrawLinearGradient is used in
presentation mode, export to pdf, swf, emf, and wmf. The exports to png
and jgp are OK in AOO3.5. I havn't tested other formats.



For all exports which are nowadays still based on metafiles the solution
should be to rewrite/modify these exports to be based on primitives in
the future.



Do I understand you correct, that you think, it is not worth to correct
OutputDevice::ImplDrawLinearGradient? But the effort should be to make
it totally superfluous?


No. I appreciate and (more than) welcome when you correct the behaviour
in Ou

Re: Is there an Ubuntu repo for AOO?

[RGB ES]

2012/9/13 Fernando Cassia 

> Is there a repo for Ubuntu users to install AOO and get updates
> automatically via the system´s package manager (while at the same time
> blocking the LO components that cause conflicts with AOO?).
>
> should there be one?
>
> FC
>


Something like this?

http://sourceforge.net/projects/apacheoo-deb/files/debian/

No idea how this repo works: I'm on the RPM land since ever.

Regards
Ricardo

Re: Is there an Ubuntu repo for AOO?

[Fernando Cassia]

On Thu, Sep 13, 2012 at 11:43 AM, RGB ES  wrote:

> 2012/9/13 Fernando Cassia 
>
> > Is there a repo for Ubuntu users to install AOO and get updates
> > automatically via the system´s package manager (while at the same time
> > blocking the LO components that cause conflicts with AOO?).
> >
> > should there be one?
> >
> > FC
> >
>
>
> Something like this?
>
> http://sourceforge.net/projects/apacheoo-deb/files/debian/
>
> No idea how this repo works: I'm on the RPM land since ever.
>
> Regards
> Ricardo
>

Thanks, that´s what I was looking for. I´m a Fedora user myself, but was
asked about this in another Spanish speaking list of LatAm Ubuntu users...

FC

Re: Is there an Ubuntu repo for AOO?

[Kay Schenk]

On 09/13/2012 07:46 AM, Fernando Cassia wrote:

On Thu, Sep 13, 2012 at 11:43 AM, RGB ES  wrote:


2012/9/13 Fernando Cassia 


Is there a repo for Ubuntu users to install AOO and get updates
automatically via the system´s package manager (while at the same time
blocking the LO components that cause conflicts with AOO?).

should there be one?

FC




Something like this?

http://sourceforge.net/projects/apacheoo-deb/files/debian/

No idea how this repo works: I'm on the RPM land since ever.

Regards
Ricardo



Thanks, that´s what I was looking for. I´m a Fedora user myself, but was
asked about this in another Spanish speaking list of LatAm Ubuntu users...

FC



Fernando --

Let us know how this worked out for the Ubuntu user. I had intended to 
add this kind of information to the Linux Install area on the 
Documentation wiki for Linux installs--


http://wiki.openoffice.org/wiki/Documentation/FAQ/Installation/How_do_I_install_OpenOffice.org_on_Linux%3F

but got sidetracked with other things.

Well maybe I should start another thread on this so others could help 
maintain this information. Hmmm...





--

MzK

"We never sit anything out. We are cups, constantly and quietly
 being filled.  The trick is, knowing how to tip ourselves over and
 let the beautiful stuff out."
 -- Ray Bradbury, "Zen in the Art of Writing"

[Call-for-Review] Bug 119853 - [From Symphony]placeholder in pptx changed in AOO3.4

[Bingbing Ma]

Hi All,

 I have fixed a bug https://issues.apache.org/ooo/show_bug.cgi?id=119853,
which lose empty placeholder after loading PPTX files.

Anyone can help to review the fix, thanks!

-- 
Thanks
Best Regards

Re: [DISCUSS]Actually attach a list style to the "Numbering #" paragraph styles

[chengjh]

That's a good topic.

On Thu, Sep 13, 2012 at 10:15 PM, RGB ES  wrote:

> On Writer, you have paragraph styles and numbering styles, and it is
> possible to call the second kind of styles from the first ones in order to
> build a series of paragraphs with automatic numbering or bullets.
>
> On its default configuration, Writer offers a series of paragraph styles
> called "Numbering #", with # going from 1 to 10 (and "Start", "Cont." and
> "End" variants of all of them), as well as paragraph styles called "List
> #".
>
> The problem is that those paragraph styles cannot be used out of the box to
> make numbered lists or bullets because they do not have a numbering style
> associated: the "Numbering style" on the "Outline & Numbering" tab inside
> the style properties is set to "None" on all those styles.
>
> On the current form, those paragraph styles do not fulfil any purpose and
> every now  and then (not very often, that's true) we have on the forums
> confused users that do not understand why those "Numbering" styles do not
> do numbering at all.
>
Agree. At least, from the names,end users will be confused.
[1]The series of para styles are named by the format "List X" and
"Numbering X"(X:1-5)), but after applying the styles to paragraphs,end
users don't get the numbered or bullet results.I am sure very few end users
can know their usages.
[2]When switching to "List Styles",end users will also see series of built
in Numbering Styles with the same name format  "List X" and "Numbering
X"(X:1-5))...For end users, it is difficult to know their difference.

I propose:
A)Re-structure the names of these paragraph styles with the name
format  "List X" and "Numbering X"(X:1-5)) to provide clear semantic.
B)Provide preview capability for these styles to let end users easily know
what the actual result will be like..
C)Provide the UI entry that can support end users to bind a expected
paragraph style to a level of a numbering list style,thus end users can use
the paragraph style to format paragraph directly because it is not enough
to just bind a paragraph to a numbering list style,the level info is
necessary.


> I think the default built-in template should be changed to actually
> associate numbering styles to those paragraph styles.
>
> See this old request on bugzilla
>
> Bug 42280 - Numbering and List paragraph styles should have numbering style
> by default
>
> https://issues.apache.org/ooo/show_bug.cgi?id=42280
>
> What do you think?
>
> Regards
> Ricardo
>



-- 

Best Regards,Jianhong Cheng

[Call-for-Review] issue 119660 - [From Symphony]Page number lost if save template to doc format

[ZuoJun Chen]

Hi all,

 I have a fix to for bug 119660,  please review the patch attached to:

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

Thanks in advance.

Regards - Zuojun

Re: Clipart library

[Armin Le Grand]

Hi Joost,

On 13.09.2012 15:43, Joost Andrae wrote:

Hi Armin,

I can still reproduce the behavior described:

Open eg.
http://openclipart.org/detail/172011/racing-helmet-by-gnokii-172011 in
Firefox and drag the SVG file to the Gallery in AOO. On my system (Win7
Pro 64 Bit) the resulting Gallery entry is a BMP file.


It is also a bitmap file when dragging it to Inkscae. This is because 
the D&D contains a bitmap already. To get the svg file, you need to 
right-click on the helmet and use 'save link as' and save it somewher. 
From there, you can drag the real SVG.


HTH!


Joost wrote somewhere in this thread that SVG dropped to the gallery is
converted to bitmap formats. I checked this and it is not true.

When using a SVG from the gallery and svaing the document, I checked the
SVG embedded into the ODF format - it's exactly (byte by byte) the
original SVG I was dropping to the gallery.

Works as intended/expected.



Kind regards, Joost

[Call-for-​​Review] [Filter]Bu​g 119477(import bullet's startwith value error)

[ying sun]

Hi, all

 I had a fix for bug 119477(
https://issues.apache.org/ooo/show_bug.cgi?id=119477
)
 Could anyone help me to review the fix?
Thank you!

Re: Problems with axial gradient and low color steps

[Armin Le Grand]

Hi Regina,

On 13.09.2012 22:43, Regina Henschel wrote:

Hi Armin,

comments inline.

Armin Le Grand schrieb:

Hi Regina,

On 08.09.2012 21:27, Regina Henschel wrote:

Hi Armin,

Armin Le Grand schrieb:

 Hi Regina,

On 06.09.2012 21:35, Regina Henschel wrote:

Hi all,

I see a lot of problems with axial gradients, but I'm not sure about
the
desired behavior.
Please have look at attachment
https://issues.apache.org/ooo/attachment.cgi?id=79324 in bug
https://issues.apache.org/ooo/show_bug.cgi?id=120604

Problem (1): How many color steps has an axial gradient, if the user
set
it to n steps in the UI? Old versions (SO5.2 to at least OOo2.4.3)
make
it in n steps, with n/2 steps blending color "up" and n/2 steps
blending
color "down". Around OOo3.2.1 this behavior was changed so that (n-1)
steps "up", 1 step in the middle and (n-1) steps down. In AOO we have
now (n-1) steps "up" and (n-1) steps "down". The ODF does not specify
it.


How many stripes should the shape show, if the user sets the step count
to 5 ?
5 -> old behavior, does not fit at all
8 -> behavior in 3.4.1 and 3.5
9 -> behavior in 3.2.1, only one middle strip
10 -> I would prefer this; as in 3.2.1, but with double middle strip


I agree. I first thought about 9, but 10 is the exactly once mirrored
behaviour of 'linear'. Do we have a task for it?



I have written https://issues.apache.org/ooo/show_bug.cgi?id=120604.


Okay, I can use that.





Problem (2): What colors should the steps have? In the old version the
colors for "up" and "down" where different, what I think has been a
bug.


Yes. Also the step count was wrongly interpreted. There are numerous
errors in the old, VCL-based gradient painters.


In AOO 3.4.1 version neither the start not the end color is used, only
values between.


Start and end color should be used (if visible). In the Yellow/Green
example this seems to be okay.


Compare it with pure color green and pure color yellow and compare it
with a linear gradient with green -> yellow and linear gradient with
yellow -> green.

The linear gradient includes the start color and excludes the end color.
(I think that it would be better the other way round, because the start
color can be included via border. But that is a different problem.)

The axial gradient has neither start nor end color.


I see this both as errors. Start and end color should always be used. Do
we have tasks for this?



I think, that it can be handled together in
https://issues.apache.org/ooo/show_bug.cgi?id=120604, because it is all
in the same file.


Okay, agreed.






Problem (3): The old gradients are still used for presentation mode,


AFAIK presentation has its own gradient rendering, targeted at
system-specific canvases. If redoing this, it sould use the primitives
directly (one day). It's an export.


converting to bitmap,


Should use primitives nowadays. If not, should be changed to do so.


Indeed, that is fixed in AOO3.5. It is correct for export to png and jpg
too in AOO3.5.

Copy and Save as "GDI metafile" is better in AOO3.5 than in AOO3.4.1.
The gradient is the same as for the shape and the gradient rotates
together with the shape, as expected for a picture. But 'Break' and
'Convert to bitmap' are wrong. 'Convert to bitmap' looses the rotation
which comes from the shape rotation and 'Break' looses the step count in
addition. But that is not specific for axial gradient.




export to pdf


Yes, is based on and 'paints' metafiles (but not with the VCL
mechanisms). It's an export and should be changed to primitive usage
one
day.


Mh. If I export it to pdf using my build with my changes in
OutputDevice::ImplDrawLinearGradient, I can see exact this changes.


Okay, so export to metafile uses OutputDevice::ImplDrawLinearGradient.




and flash.


Not sure about this, also an export.


I think, that needs to be
fixed. I have looked around, and think, that it is in
OutputDevice::ImplDrawLinearGradient in
\main\vcl\source\gdi\outdev4.cxx. Is that right? If yes, are other
places effected as well? Should it be fixed or is someone working on a
more general solution?


It *could* be fixed there if really used. Have You tried to set breaks
(pr fprintfs) to check this? Most usages should not use it.


No. I have changed the colors and steps in
OutputDevice::ImplDrawLinearGradient and can see those changes using the
resulting build.


Good.



If it is used, it could be made to work using temp primitives
internally
to ensure equal rendering.


As far as I have tested, OutputDevice::ImplDrawLinearGradient is used in
presentation mode, export to pdf, swf, emf, and wmf. The exports to png
and jgp are OK in AOO3.5. I havn't tested other formats.



For all exports which are nowadays still based on metafiles the
solution
should be to rewrite/modify these exports to be based on primitives in
the future.



Do I understand you correct, that you think, it is not worth to correct
OutputDevice::ImplDrawLinearGradient? But the effort should be to make
it totally 

Re: [QA CALLFORREV​IEW] [testuno]C​heck paper format in SW via UNO API

[Carl Marcum]

On 09/13/2012 07:17 AM, Xiao Ting Xiao wrote:

attach the patch, use uno to test page format, include

1. page's width/height, orientation, margin
2. page's background, include back color and back graphic
3. page's header/footer settings, such as margin, spacing, height,
border, background

also include 3 methods in SWUtil.java

one update in sw/DocumentTest.java to apply latest version of
prepareData() method in Testspace.java

Please help reivew, it has been submitted with bug 120784,
https://issues.apache.org/ooo/show_bug.cgi?id=120784

On Fri, Aug 31, 2012 at 6:54 PM, Xiao Ting Xiao  wrote:


Hi all,

One patch for UNO automation test script has been submitted with *Bug
120784,
https://issues.apache.org/ooo/show_bug.cgi?id=120784

This patch include:
paper's width, height
paper's orientation
paper's margin
paper's background

Please help review.






I updated:
Updated to revision 1384617.

$ patch -p0 -i /home/carl/Downloads/pageFormat1.patch
(Stripping trailing CRs from patch.)

$ patch -p0 -i /home/carl/Downloads/pageFormat1.patch
(Stripping trailing CRs from patch.)
patching file testuno/source/testcase/uno/sw/DocumentTest.java
Hunk #1 FAILED at 43.
1 out of 1 hunk FAILED -- saving rejects to file 
testuno/source/testcase/uno/sw/DocumentTest.java.rej

(Stripping trailing CRs from patch.)
patching file testuno/source/testcase/uno/sw/page/CheckBackground.java
(Stripping trailing CRs from patch.)
patching file testuno/source/testcase/uno/sw/page/CheckFooterHeader.java
(Stripping trailing CRs from patch.)
patching file 
testuno/source/testcase/uno/sw/page/CheckFooterHeaderBackground.java

(Stripping trailing CRs from patch.)
patching file 
testuno/source/testcase/uno/sw/page/CheckFooterHeaderBorder.java

(Stripping trailing CRs from patch.)
patching file testuno/source/testcase/uno/sw/page/CheckPage.java
(Stripping trailing CRs from patch.)
patching file testuno/source/testlib/uno/SWUtil.java
Hunk #1 FAILED at 25.
Hunk #2 FAILED at 53.
Hunk #3 FAILED at 183.
3 out of 3 hunks FAILED -- saving rejects to file 
testuno/source/testlib/uno/SWUtil.java.rej


best regards,
Carl

Re: [Call for Test] [Feature]Add the List Level attribute for paragraph styles in Aoo Writer

[Du Jing]

Hi HuaiDong,can you review my prepared test case for this feature?

On Mon, Sep 10, 2012 at 10:27 AM, Du Jing  wrote:

> I has reviewed the feature scope,and prepared test case in Test 
> Link->Test
> Specification-->AOO Writer->Styles and Formatting->List style as below
> http://aootesting.adfinis-sygroup.org/index.php
>
>
> On Fri, Sep 7, 2012 at 3:51 PM, Huaidong Qiu wrote:
>
>> issue link https://issues.apache.org/ooo/show_bug.cgi?id=120620
>>
>>
>> Scope:
>> 1)The list level attribute of para style will be exported to odt with
>> defined format.
>> 2)The exported list level attribute of para style will be imported
>> into data model of Aoo Writer successfully
>> 3)The list level attribute of para style will be recorded in data
>> model of Aoo Writer
>>
>> Wiki:
>> http://wiki.openoffice.org/wiki/Writer/NumberingEnhancementforMSInteroperability
>>
>
>