date:20110719

Re: [Libreoffice] [libreoffice-l10n] [ANN] LibreOffice 3.4.2 RC1 available

2011-07-19 Thread Cor Nouws


Hi all,

Nino Novak wrote (14-07-11 22:48)

Am Donnerstag, 14. Juli 2011, um 14:29:53 schrieb Florian Effenberger:


The list of fixed bugs in this release is here:

http://dev-builds.libreoffice.org/pre-releases/src/bugfixes-libreoffice-3-4-release-3.4.2.1.log


for a clickable version, look at
http://wiki.documentfoundation.org/User:Nnino/Drafts/bugfixes3.4.2


Thanks for the lists,
I see that bug #37488 is not listed, though it is fixed.
This not being listed is caused by the fact that it is (IMO 
unfortunately) marked as WORKSFORME. See my latest comment in the issue:

https://bugs.freedesktop.org/show_bug.cgi?id=37488#c67

Cheers

--
 - Cor
 - http://nl.libreoffice.org

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PATCH] Replace List with std::vector ImplBmpObj*

2011-07-19 Thread Matúš Kukan

Hi Joe,

On 19 July 2011 06:40, Joseph Powers jpower...@cox.net wrote:
 I'd like someone doing a Unix build to review this for me. I compile Mac and 
 this is Unix only code so I don't just want to push and hope...

First I thought it would compile and want just to write something but
then I tried and it doesn't.
But my question is:
Would not it be better to replace List with std::list ? Or if vector I
don't like erase because it's not effective.
In this case I'd use maBmpList.pop_back(). On the first sight I
thought you have mistake in:

 void ImplSalBitmapCache::ImplRemove( X11SalBitmap* pBmp )
 {
-for( ImplBmpObj* pObj = (ImplBmpObj*) maBmpList.Last(); pObj;
pObj = (ImplBmpObj*) maBmpList.Prev() )
+for( size_t i = maBmpList.size(); i; )
 {
+ImplBmpObj* pObj = maBmpList[ --i ];
 if( pObj-mpBmp == pBmp )
 {
-maBmpList.Remove( pObj );
+maBmpList.erase( maBmpList.begin() + i );
 pObj-mpBmp-ImplRemovedFromCache();
 mnTotalSize -= pObj-mnMemSize;
 delete pObj;

But then I realized you are decreasing i in ImplBmpObj* pObj = maBmpList[ --i ];
So - maBmpList.erase( maBmpList.begin() + i ); is in fact pop_back and
it's effective but personally I'd use the latter to avoid mistakes.

Now here is what I got on 32bit Ubuntu:

vcl/unx/generic/gdi/salbmp.cxx: In member function ‘void
ImplSalBitmapCache::ImplAdd(X11SalBitmap*, sal_uLong, sal_uLong)’:
vcl/unx/generic/gdi/salbmp.cxx:1218: error: invalid use of incomplete
type ‘struct ImplSalBitmapCache::ImplBmpObj’
vcl/inc/unx/salbmp.h:253: error: forward declaration of ‘struct
ImplSalBitmapCache::ImplBmpObj’
vcl/unx/generic/gdi/salbmp.cxx:1226: error: invalid use of incomplete
type ‘struct ImplSalBitmapCache::ImplBmpObj’
vcl/inc/unx/salbmp.h:253: error: forward declaration of ‘struct
ImplSalBitmapCache::ImplBmpObj’
vcl/unx/generic/gdi/salbmp.cxx:1227: error: invalid use of incomplete
type ‘struct ImplSalBitmapCache::ImplBmpObj’
vcl/inc/unx/salbmp.h:253: error: forward declaration of ‘struct
ImplSalBitmapCache::ImplBmpObj’
vcl/unx/generic/gdi/salbmp.cxx:1227: error: invalid use of incomplete
type ‘struct ImplSalBitmapCache::ImplBmpObj’
vcl/inc/unx/salbmp.h:253: error: forward declaration of ‘struct
ImplSalBitmapCache::ImplBmpObj’
vcl/unx/generic/gdi/salbmp.cxx:1230: error: invalid use of incomplete
type ‘struct ImplSalBitmapCache::ImplBmpObj’
vcl/inc/unx/salbmp.h:253: error: forward declaration of ‘struct
ImplSalBitmapCache::ImplBmpObj’
vcl/unx/generic/gdi/salbmp.cxx: In member function ‘void
ImplSalBitmapCache::ImplRemove(X11SalBitmap*)’:
vcl/unx/generic/gdi/salbmp.cxx:1240: error: invalid use of incomplete
type ‘struct ImplSalBitmapCache::ImplBmpObj’
vcl/inc/unx/salbmp.h:253: error: forward declaration of ‘struct
ImplSalBitmapCache::ImplBmpObj’
vcl/unx/generic/gdi/salbmp.cxx:1243: error: invalid use of incomplete
type ‘struct ImplSalBitmapCache::ImplBmpObj’
vcl/inc/unx/salbmp.h:253: error: forward declaration of ‘struct
ImplSalBitmapCache::ImplBmpObj’
vcl/unx/generic/gdi/salbmp.cxx:1244: error: invalid use of incomplete
type ‘struct ImplSalBitmapCache::ImplBmpObj’
vcl/inc/unx/salbmp.h:253: error: forward declaration of ‘struct
ImplSalBitmapCache::ImplBmpObj’
vcl/unx/generic/gdi/salbmp.cxx:1245: warning: possible problem
detected in invocation of delete operator:
vcl/unx/generic/gdi/salbmp.cxx:1239: warning: ‘pObj’ has incomplete type
vcl/inc/unx/salbmp.h:253: warning: forward declaration of ‘struct
ImplSalBitmapCache::ImplBmpObj’
vcl/unx/generic/gdi/salbmp.cxx:1245: note: neither the destructor nor
the class-specific operator delete will be called, even if they are
declared when the class is defined.
vcl/unx/generic/gdi/salbmp.cxx: In member function ‘void
ImplSalBitmapCache::ImplClear()’:
vcl/unx/generic/gdi/salbmp.cxx:1257: error: invalid use of incomplete
type ‘struct ImplSalBitmapCache::ImplBmpObj’
vcl/inc/unx/salbmp.h:253: error: forward declaration of ‘struct
ImplSalBitmapCache::ImplBmpObj’
vcl/unx/generic/gdi/salbmp.cxx:1258: warning: possible problem
detected in invocation of delete operator:
vcl/unx/generic/gdi/salbmp.cxx:1258: warning: invalid use of
incomplete type ‘struct ImplSalBitmapCache::ImplBmpObj’
vcl/inc/unx/salbmp.h:253: warning: forward declaration of ‘struct
ImplSalBitmapCache::ImplBmpObj’
vcl/unx/generic/gdi/salbmp.cxx:1258: note: neither the destructor nor
the class-specific operator delete will be called, even if they are
declared when the class is defined.

I was not investigating where the problem is, I think you can handle it.

All the best,
Matus
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs

2011-07-19 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=35673

Caolán McNamara caol...@redhat.com changed:

   What|Removed |Added

 Depends on||38095

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [REVIEW] cherry-picking fix for fdo#38095, character classification for font selection

2011-07-19 Thread Caolán McNamara

On Tue, 2011-07-19 at 01:14 +0900, Takeshi Abe wrote:
 Hi all,
 
 According to a discussion on the Japanese local mailing list,
 the following issue may prevent some users from migrating
 to 3.4.x series:
 https://bugs.freedesktop.org/show_bug.cgi?id=38095

Looking for ack-s for 3-4 and 3-4-2.

The goal is to reset the classification of the entire full+half width
range back to ASIAN, i.e. consider the 0-9 and A-z full-width forms as
ASIAN despite their UAX24 classification as Latin, because that's the
way it used to be done and documents change otherwise, and because the
full-width Latin/Common Numerals exist in order to be the same cell
width as full-width CJK chars so they should be rendered with a CJK
font, which is all we want this particular classification to determine
for us.

I also reset back the entire number-forms range to WEAK as well, i.e.
the single-glyph roman-numerals i, IV, etc. seeing as they also
really only exist in order to be nicely rendered in CJK vertical text
mode.

http://cgit.freedesktop.org/libreoffice/libs-gui/commit/?id=e76c8d80009c8e29abf0447b7edc157eb42c9e56

looks big, but its basically just if old explicitly assigned range use
old assignment else do probably technically correct thing

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] converting to new build system

2011-07-19 Thread Matúš Kukan

Hi Mike,

On 19 July 2011 01:07, Mike Eberdt libr...@comcast.net wrote:
 My 'dmake' fu is basically non-existent, so I haven't poked at this
 seriously yet.  And as I understand it, a transition is underway to GNU
 make, so I guess I've been a bit reluctant to put a lot of time into
 learning the old build system.  However, I didn't notice any info in the
 Developers section of the Wiki about using the new build system, or helping
 with the migration, etc.  Is this something that mere mortals can contribute
 to, or should I just wait for the grand unveiling? :)

I'm really glad you wrote this. I think there is always possibility to help.
For example adding visibility marks to exported objects should be
easy, there are still some .map files to be processed.

I'm not sure but may be it's already planned to write some info somewhere.
If there are people willing to help, that's great.
Moreover, there is always possibility to learn.

I have to work now on converting modules to gbuild, so I could move on
with my GSoC project.
Maybe you could help.

Best,
Matus
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [REVIEW] cherry-picking fix for fdo#38095, character classification for font selection -- 2 more reviews needed

2011-07-19 Thread Fridrich Strba

I cherry-picked to the 3-4 branch, 2 more reviews needed for the current
3.4.2 I guess.

On Tue, 2011-07-19 at 09:50 +0100, Caolán McNamara wrote:
On Tue, 2011-07-19 at 01:14 +0900, Takeshi Abe wrote:
Hi all,

According to a discussion on the Japanese local mailing list,
the following issue may prevent some users from migrating
to 3.4.x series:
https://bugs.freedesktop.org/show_bug.cgi?id=38095

Looking for ack-s for 3-4 and 3-4-2.

The goal is to reset the classification of the entire full+half width
range back to ASIAN, i.e. consider the 0-9 and A-z full-width forms as
ASIAN despite their UAX24 classification as Latin, because that's the
way it used to be done and documents change otherwise, and because the
full-width Latin/Common Numerals exist in order to be the same cell
width as full-width CJK chars so they should be rendered with a CJK
font, which is all we want this particular classification to determine
for us.

I also reset back the entire number-forms range to WEAK as well, i.e.
the single-glyph roman-numerals i, IV, etc. seeing as they also
really only exist in order to be nicely rendered in CJK vertical text
mode.

64 matches

Mail list logo