Re: build failure: sc_ucalc.test - cppunittester abort trap (core dumped)
Le 29/03/12 13:29, R Skinner a écrit : Hi again, For what its worth, the build from master is currently failing for me at the same point in the sc cppunit tests on Linux 32bit Ubuntu Oneiric, despite repeated cleans and pulls from git master, so it would appear that the problem is not just BSD specific. Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
GSOC 2012 , submitting a patch for easy hack
Hi Everyone ,
I am GSOC 2012 Aspirant and a 2nd year undergraduate from NMIMS University,
Mumbai.
I am interested in the android development concerning the Idea "Use your
SmartPhone to remote-control slideshow" . I plan to use the WLAN and
Bluetooth to achieve this. Also I plan to add a feature to this app , to
change slides by using the accelerometer phone sensor , so that user can
change the slide by simply giving a jerk in the required direction. Till now
i have managed to get a reasonable stable connection between a laptop and
phone which can find each other when connected to the same network.
Also , I am new to open-source and community based development , I managed
to patch an Easy Hack
Easy Hack 47864 - UI: Add HELP button and content to Starmath Font size
dialog
I have committed this to my local git repository and re-based to master
branch , however i am having trouble making a patch file , I get this output
by the command git show :
commit 3429351866f18e20693fb97b70d6d2c40b62f259
Author: Karan
Date: Sat Mar 31 08:27:10 2012 +0530
Added help button in Fontsize dialog of starmath
diff --git a/starmath/inc/dialog.hxx b/starmath/inc/dialog.hxx
index de3a02f..9415114 100644
--- a/starmath/inc/dialog.hxx
+++ b/starmath/inc/dialog.hxx
@@ -143,11 +143,13 @@ class SmFontSizeDialog : public ModalDialog
FixedText aFixedText8;
MetricField aBorderSize;
FixedLine aFixedLine1;
+HelpButton aHelpButton;
OKButtonaOKButton1;
CancelButtonaCancelButton1;
PushButton aDefaultButton;
DECL_LINK(DefaultButtonClickHdl, Button *);
+DECL_LINK(HelpButtonClickHdl, Button *);
public:
SmFontSizeDialog(Window *pParent, bool bFreeRes = true);
diff --git a/starmath/source/dialog.cxx b/starmath/source/dialog.cxx
index 4895514..1c961ee 100644
--- a/starmath/source/dialog.cxx
+++ b/starmath/source/dialog.cxx
@@ -43,6 +43,7 @@
#include
#include
#include
+#include "vcl/help.hxx"
#include
#include
#include
@@ -439,6 +440,17 @@ IMPL_LINK( SmFontSizeDialog, DefaultButtonClickHdl,
Button *, EMPTYARG /*pButton
return 0;
}
+IMPL_LINK( SmFontSizeDialog, HelpButtonClickHdl, Button *, EMPTYARG
/*pButton*/ )
+{
+// start help system
+Help* pHelp = Application::GetHelp();
+if( pHelp )
+{
+pHelp->Start( rtl::OUString( RTL_CONSTASCII_USTRINGPARAM(
"HID_SMA_FONTSIZEDIALOG" ) ), &aHelpButton );
+}
+return 0;
+}
+
:
How can I get a patch file for my commit , I tried the instructions on wiki
page , but that did not generate any file :(
--
View this message in context:
http://nabble.documentfoundation.org/GSOC-2012-submitting-a-patch-for-easy-hack-tp3872816p3872816.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [ANN] LibreOffice 3.5.2 RC2 test builds available
Hi Tor, all Tor Lillqvist-2 wrote > > My *personal* fear is that if we start doing these kinds of > suggestions, we will get into nasty nationalistic arguments... > > "We here in Freedonia certainly don't need any Sylvanian dictionary; > we will never forget how they destroyed our Holy Bicycle of Yendor at > the Glorious Battle of Strawberry Fields in A.D. 567!" > Well, by installing all, not only you waste a "measly" 178Mb(!!!) on dictionaries only but you are already offending the Freedonians... Tor Lillqvist-2 wrote > > On the other hand, not suggesting any except that for the UI language > selected, also opens up a Pandora's Box, "Don't you idiots know that > Baklavian is also an official language here in Equatorial Kundu, all > EqK citizens are required by law to be able to write documents in > either languages, this is an insult to the Kundu People!" > :) Unless there are a set of rules (e.g. for Equatorial Kundu include Kundulese and Baklavian, etc) I think that if users see their own language selected they will be happy and since the installer options are saved, even if they have to select another language, it is a one time operation... Personally I think that less is more :) and saving 178Mb on dictionaries only is probably a good idea... Regards, Pedro -- View this message in context: http://nabble.documentfoundation.org/ANN-LibreOffice-3-5-2-RC2-test-builds-available-tp3865776p3872362.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [ANN] LibreOffice 3.5.2 RC2 test builds available
Hi Michael, all Michael Meeks-2 wrote > >> Since each dictionary is an Extension and extensions are checked at load >> time, having dozens of un-needed dictionaries loaded not only makes first >> load take ages but surely increases memory usage ? (I haven't tested this >> but >> I can tell for sure that dev builds which only have three languages load >> significantly faster) > > It'd be interesting to compare like for like; in theory there is no > reason at all why having a lot of dictionaries installed -needs- to > cause grief, it'd be interesting to get some hard warm-start time / > memory numbers on that; if you can (?) > Actually you are right. It is not the dictionaries. I did a parallel install of LO 3.5.2.2 and run it 3 times with all dictionaries and 3 times only with the English dictionary. The load time was consistently 29 seconds (a little slow...) Now the interesting part is that I got a dev build from the same day (3.5.3.0 which I know it's not the same code but I believe that is not what is making the difference) and the load time was repeatedly 4 seconds!!! I will investigate some more as time allows ;) Regards, Pedro -- View this message in context: http://nabble.documentfoundation.org/ANN-LibreOffice-3-5-2-RC2-test-builds-available-tp3865776p3872338.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: intermittent flaw in gnumake deps on Win32 ..
On Fri, Mar 30, 2012 at 6:56 AM, Christian Lohmaier wrote: > On Fri, Mar 30, 2012 at 1:05 PM, Matúš Kukan wrote: >> On 30 March 2012 11:36, Michael Meeks wrote: >>> Regina's problem comes down to a corrupt .d file. >>> [...] >>> One more data-point, that file was exactly 4096 bytes large: >> >> What does that mean ? > > Well - it is either a coincidence, or not.. A multiple of 1024 i.e > exactly 4KB in size.. and 4K is the typical memory page, and the kidn of unit you would see for partial write. the final write to device. this behavior can be seen if you have a running process that write to a log and look at the log file while it is running the log will grow by 4K increment until you ffllush() of fclose() the file. So that what one would expect to see if the filter-showincludes.pl was interrupted abruptly. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: build failure: sc_ucalc.test - cppunittester abort trap (core dumped)
Hi, Sorry, I'm not much of help... On Thu, Mar 29, 2012 at 13:29, R Skinner wrote: > [I tried at the users list but was advised I should post here instead] > > Hi, I'm new here, and I'm driven here by desperation. I'm trying to build > libreoffice-3.4.5.2 on FreeBSD and it is failing the testing stage. I'm > running out of time for a client to pick up, so I need to fix this now and I > need some pointers on how to figure out whats wrong here. > I haven't tried to build LO on FreeBSD, but others have. Have you searched the ML to find some clue to solve your problem? This for instance: http://lists.freedesktop.org/archives/libreoffice/2012-February/027383.html /Albert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Fwd: [tdf-discuss] LibreOffice Version Mismatch/Conflict
2012/3/30 Petr Mladek : > Andras Timar píše v So 24. 03. 2012 v 16:30 +0100: >> Hi Petr, >> >> See the mail below. Is there a reason why we don't update VERSIONMICRO >> in solenv/inc/minor.mk? > > I am not sure what the version is for. I remember that we updated some > version in this file and it broke some import/export hacks for backward > compatibility. As far as I remember, I introduced the VERSIONMICRO variable before 3.5 feature freeze, and it is used only in File Version field of Windows executables. The same is true for VERSIONMAJOR and VERSIONMINOR. It is safe to bump them, when necessary. > > For example, see the check for nUPD == 350 in the recent commit > http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=befb1c7e26b79ae97d802659f3386882d4044251 > > I am not sure what exact version string affects getBuildIds() function. > I just know that we need to be careful with modifying versions in that > minor.mk :-) That 350 (and other values at this location) look like the version string of the Master Workspace (MWS), it is not constructed from VERSIONMAJOR+VERSIONMINOR+VERSIONMICRO. This version number is generated by configure script, in line 3383. It is AC_PACKAGE_VERSION+0 and it is called UPD. AC_PACKAGE_VERSION is defined by AC_INIT, it is hardcoded in configure.in. The getBuildIds() function reads UPD (and build id, that is defined in minor.mk as well). > > Ugh, the versioning is a real mess. The versions are defined on many > locations and used different ways. It is a good candidate for general > cleanup. Whoever would like to dig into it, please step up. Now, for the 3.5.3 it would solve the inconsistencies, if you bumped VERSIONMICRO from minor.mk to 3, and if you displayed 3.5.3.buildid in About box. That way file versions on Windows, About box version and MSI version would be the same. Best regards, Andras ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-ux-advise] named formatting attributs overwrite automatic formatting attributs (paragraph / character)
Hello, For me, character style and paragraph style should behave the same. I change my mind and think that character style should behave like the paragraph style : If you apply a style on something (text or paragraph) the style should overwrite the preview style and directs attributs on this something. If you apply a direct attribut on something the direct attribut should be merge with the preview style and direct attribut on this something. But I don’t like very much the idea to force people to use style formatting… Regards Maxime de Roucy -- Maxime de Roucy Groupe LINAGORA - OSSA 80 rue Roque de Fillol 92800 PUTEAUX Tel. : 0 810 251 251 Le vendredi 30 mars 2012 à 07:53 +0200, Jean-Francois Nifenecker a écrit : > Hi, > > Le 29/03/2012 22:09, Rafael Rocha Daud a écrit : > > > > This is intended behaviour. LibreOffice makes an assumption that when > > you apply a style you want the paragraph to look like that, so it > > overrides the direct formatting that had been applied to the whole > > paragraph. The assumption works otherwise when the direct formatting was > > affecting only a portion: you want the paragraph to look like the style, > > but you want that portion to retain it's direct formatting. > > > > Generally, direct formatting overrides styles, but they are not really > > meant to be used in conjunction, but you still can if you want to. The > > best thing to do in your specific case is to change the style itself so > > it applies your bold atribute (or you may create a new style, based on > > that one, to do that). The second best thing is to apply the direct > > formatting after applying the style (but remember you will have to do > > that for each paragraph you want that atribute in, and you will have to > > re-do it if you later change the paragraph style again. > > > > To me there are two questions : the one Maxime asked, ie the homogeneity > between paragraph style and character style use. The second one is > whether the tool should encourage to a correct use of the tool or not. > > Homogeneity > > I share Maxime's thoughts and, imo, both style types should apply the > same, iow, applying a style should replace the underlying formatting > (direct or style). > > Correct use > > Styles are the first reason to adopt LibreOffice. This should be highly > emphasized and promoted. As a trainer, I always bring questions back to > styles: "3 times upon 2, using a style solves the problem" (yes, 3 times > upon 2 ;). Hence, direct formatting should be discouraged. Better yet, > for instance, pressing the "B"old toolbutton should apply the correct > character style (bold emphasis by default) instead of setting the bold > property to the underlying characters. > > Side note: I feel a very important need for table styles in Writer. > signature.asc Description: This is a digitally signed message part ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Patch review for About Dialog redesign
Hi, So this is my first time contributing to LibreOffice so I was wondering if I could have some critique on my patch. All the info is this the bug report https://bugs.freedesktop.org/show_bug.cgi?id=31022 but basically what it does is make the About Dialog look like this: https://bugs.freedesktop.org/attachment.cgi?id=59287 Thanks -- Andrew ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-commits] .: distro-configs/LibreOfficeMinGW.conf distro-configs/LibreOfficeWin32.conf distro-configs/LibreOfficeWin64.conf
On Friday 30 of March 2012, Michael Meeks wrote: > On Fri, 2012-03-30 at 08:58 +0200, Stephan Bergmann wrote: > > On 03/30/2012 08:51 AM, Stephan Bergmann wrote: > > > Looks like this kills MinGW builds > > > > Ah, looks like Luboš already fixed it, with > > e20fa170160e1bb1953ad171e092edfb3de531af. > > At root there is some *serious* badness that crept in here. I'd really > like someone to spend some time to unwind how exactly we managed to > screw up our configure.in -so- badly and it remain un-detected for so > long. Assuming I'm not missing some bigger badness, this specific problem was caused by 2130deb2d13f7cbb5b5e55c061ad794e47e6999d , which is less than 2 months old, and it wasn't really anything that big. The change shouldn't have put enable_cairo_canvas on the same level like with_system_cairo, as disabling the canvas caused the internal cairo to be dragged in by things depending on it. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Android: java.lang.reflect.UndeclaredThrowableException from com.sun.star.ucb.ContentCreationException: Unable to create Content
Argh, I think I know the problem. My own mistake... I forgot to execute the run-time binary patching of a bug in the NDK's shared GNU C++ library... without that patch, catching exceptions thrown in another shared object doesn't work. I am experimenting with http://cgit.freedesktop.org/libreoffice/core/tree/android/experiments/DocumentLoader/src/org/libreoffice/android/examples/DocumentLoader.java , which unlike the unit test stuff in android/qa/sc does not use a subclass of Android's NativeActivity (or of our Bootstrap class, http://cgit.freedesktop.org/libreoffice/core/tree/android/Bootstrap/src/org/libreoffice/android/Bootstrap.java, which is a subclass of NativeActivity). Thus android_main(), http://cgit.freedesktop.org/libreoffice/core/tree/sal/android/lo-bootstrap.c#n1617 doesn't get executed. And it's android_main() that calls patch_libgnustl_shared(), http://cgit.freedesktop.org/libreoffice/core/tree/sal/android/lo-bootstrap.c#n1373 . So I just need to call (its JNI wrapper) Bootstrap.patch_libgnustl_shared() and cross-shared-library exception handling should work fine. Knock on wood... Yeah, I probably should move the patch_libgnustl_shared() call to the setup() function, so that it isn't forgotten so easily... --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Make watchdog (Re: Build failure on Windows/MSVC because of embedserv)
On Wednesday 21 of March 2012, Lubos Lunak wrote: > On Monday 19 of March 2012, Michael Meeks wrote: > > On Mon, 2012-03-19 at 07:33 +0100, Lubos Lunak wrote: > > > Oh, I see. I've already noticed this myself, and that's a good > > > explanation for Voreppe's (lack of) builds. That's a rather bad bug for > > > tinderbox builds, and we really could use a tinderbox watching over our > > > commits breaking the MSVC build (I think I fixed 5 MSVC regressions > > > last week at the very least). > > > > Yep - perhaps a re-boot-box-and-restart-build-after-4-hours of no > > watchdog ping or something ? :-) > > Nah, so crude :). I've written a make watchdog, it's currently being > tested on the Win-x86_6-fast tinderbox to see how it works in practice. Just for the record, this has now been committed to tinbuild, so whoever has a tinderbox suffering from this can update and add something like -d 600 to the arguments. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Fwd: [tdf-discuss] LibreOffice Version Mismatch/Conflict
Andras Timar píše v So 24. 03. 2012 v 16:30 +0100: > Hi Petr, > > See the mail below. Is there a reason why we don't update VERSIONMICRO > in solenv/inc/minor.mk? I am not sure what the version is for. I remember that we updated some version in this file and it broke some import/export hacks for backward compatibility. For example, see the check for nUPD == 350 in the recent commit http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=befb1c7e26b79ae97d802659f3386882d4044251 I am not sure what exact version string affects getBuildIds() function. I just know that we need to be careful with modifying versions in that minor.mk :-) Ugh, the versioning is a real mess. The versions are defined on many locations and used different ways. It is a good candidate for general cleanup. Whoever would like to dig into it, please step up. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Android: java.lang.reflect.UndeclaredThrowableException from com.sun.star.ucb.ContentCreationException: Unable to create Content
I don't understand.
The call to getContent() comes from uno::Sequence < OUString >
SfxContentHelper::GetResultSet( const String& rURL ) in
sfx2/source/bastyp/helper.cxx.
And it sure is surrounded by a try { ... } followed by catch( const
ucb::CommandAbortedException& ) { ... } catch( const uno::Exception& )
{ ... } .
css::ucb::ContentCreationException is a subclass of
css::uno::Exception. So why doesn't the second catch() work?
Is exception handling broken in the Android NDK r7b and its
gnustl_shared library? Then we will have lots of fun in the Android
port... But surely exception handling brokenness would have shown up
earlier already? Sigh, my head hurts (just figuratively speaking).
--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Bug 37361] LibreOffice 3.5 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=37361 sasha.libreoff...@gmail.com changed: What|Removed |Added Depends on||48093 -- 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
[Bug 37361] LibreOffice 3.5 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=37361 --- Comment #258 from sasha.libreoff...@gmail.com 2012-03-30 07:41:29 PDT --- regression in Impress: Bug 48093 - Impress: text in odp file looks incorrect (regression after 3.4.3) -- 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
Re: Modern font features, hacky patch
On Fri, 2012-03-30 at 16:13 +0200, Khaled Hosny wrote: > But regardless of the layout engine we use, this only affects > non-Windows non-Mac platforms, while on Windows we use Uniscribe and on > Mac we use, the now deprecated, ATSUI, which is IMHO another limitation > that we should get rid of I can't really speak for the other platforms unfortunately. They need platform-specific love. > If there is interest in this, I can try implementing optional HarfBuzz > support next to ICU so we can experiment more with this (though I'm not > the best person to do this, but I can try). Can't hurt to give it a go anyway. Even epic failure can point the next person in the right way to go. Yeah lacking Indic shaping would be a problem for right now. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
string / size bits ...
Hi there, I up-loaded the output of my string debug for a writer start: http://www.gnome.org/~michael/llog.txt.gz It ignores ref-counts, and shows real lifecycle data per string - ie. how many times a copy of this string is allocated. I'll write a script to crunch it in a bit & show what is actually kept, rather than being transiently allocated then freed during startup. Having said that, the top of the list shows no surprises: $ zcat /tmp/llog.txt.gz | grep '^+' | sort | uniq -c | sort -n -r | head -n 10 39472 +IMPLEMENTATIONS 28446 +UNO 11297 +SERVICES 9618 +ACTIVATOR 4809 +PREFIX 4809 +LOCATION 3393 +en 2576 + 1589 +en-US 1539 +SINGLETONS ... Then again - I was interested tat configmgr 'map' allocations are in the top memory consumers, rather than string allocations; but - perhaps that's down to some breakdown by size as well as by allocation site. What's your estimate of the balance between strings and other types, memory-wise ? HTH, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Modern font features, hacky patch
On Fri, Mar 30, 2012 at 01:11:59PM +0100, Caolán McNamara wrote: > On Fri, 2012-03-30 at 11:39 +0200, Steve White wrote: > > Basic features > > == > > (Background reading: search for "typographic features", "font feature > > registry", "layout tag registry".) > > > > Some features that really ought to be activated most of the time, in > > most scripts > > * ligatures for Latin and most alphabetic scripts > > * localized replacement (based on text language, region) > > * pair kerning > > * mark positioning > > So, I asked Steve to post to the list, so I could dump some experimental > code to a wider audience with its context > > Lets put graphite aside for a moment, its something of a red herring > really for a lot of these things. > > If we look at > https://bugs.freedesktop.org/show_bug.cgi?id=31821 > I've a patch there that shows that a lot of our woes with otf fonts is > probably a simple bug/lack of implementation in out ServerFont::GetTable > that it doesn't handle OpenType. freetype does it fine, but we're not > using freetype to get the tables, but parsing them outselves. > > Patch at fdo#31821 > a) hacks in using freetype to get the tables (does anyone know if there > a freetype api to just get the offset of a table and not a full copy of > it ?, we've already mmapped the file so we don't need to copy them) > b) hacks in using the icu layout engine for all text, and not just for > CTL text. I wonder if its just a performance reason that we have out own > "simple" font engine for the non-CTL case ? > c) overrides IcuFontFromServerFont::mapCharToGlyph to not filter out the > zero width joiner glyphs before applying the gsub table. The icu Indic > layout engine doesn't filter it, not sure why the non-Indic ones *do* > filter it. > > So, I reckon we should continue to refactor out font handling code to > remove various custom ttf/otf parsing and try and use more of the > freetype apis so that LibreOffice gets to know about GSUB etc tables in > opentype fonts, and maybe look into removing the simple font layout > engine and just use the icu one for all fonts. For a while now I had the idea that we should move away from ICU layout engine (which is pretty dead and serious bugs aren't fixed anymore), and replace it with HarfBuzz, but HarfBuzz's Indic support is not finished (Arabic and simple scripts are fine) and I'm waiting for its next release for that. HarfBuzz is more active, more developer friendly (though under documented at the moment) and its code base have been widely used in free software applications (more tested) and is the most feature rich free OpenType implementation. HarfBuzz would make it much simpler to implement many of the points raised above, which would be near impossible with ICU layout engine. But regardless of the layout engine we use, this only affects non-Windows non-Mac platforms, while on Windows we use Uniscribe and on Mac we use, the now deprecated, ATSUI, which is IMHO another limitation that we should get rid of and move to a unified text layout engine in all platforms (which would solve lack of OpenType support on Mac). Firefox have been doing that lately, and IMO it has the best typographic support of all browsers. If there is interest in this, I can try implementing optional HarfBuzz support next to ICU so we can experiment more with this (though I'm not the best person to do this, but I can try). Regards, Khaled ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-commits] .: distro-configs/LibreOfficeMinGW.conf distro-configs/LibreOfficeWin32.conf distro-configs/LibreOfficeWin64.conf
Hello Michael, all, On Fri, Mar 30, 2012 at 18:06, Michael Meeks wrote: > At root there is some *serious* badness that crept in here. I'd really > like someone to spend some time to unwind how exactly we managed to > screw up our configure.in -so- badly and it remain un-detected for so > long. The git history is somehow screwed up. The commit 9108788fc95f01b032b1cf6773b4d74537e5c2e1: > author: Tor Lillqvist 2011-05-28 10:05:28 (GMT) > We always need cairo now with librsvg always being used > At least, I think we do... So simplify the tests for it. removed --enable-cairo on May 2011. Next, the 54c611fa455fd5e9e8fc711c158085924f47d590: > author: Philipp Lohmann [pl] 2011-04-12 18:37:07 > (GMT) > committer: Bjoern Michaelsen 2011-06-17 > 11:51:41 (GMT) > ooo340fixes: #i117804# differentiate between ENABLE_CAIRO and > ENABLE_CAIRO_CANVAS [hg:e09be3339384] introduced --enable-cairo-canvas on June 2011. But we still *have* --enable-cairo in the tree at that time. See http://cgit.freedesktop.org/libreoffice/core/tree/configure.in?id=54c611fa455fd5e9e8fc711c158085924f47d590#n205 Last, the 81a1c065fd3c0242efa0273eba0aefeebadcd877: > author: Bjoern Michaelsen 2011-06-19 > 09:36:52 (GMT) > committer: Bjoern Michaelsen 2011-06-19 > 09:36:52 (GMT) > Merge branch 'master' into feature/gnumake4 removed --enable-cairo, accidentally with merge (?) So, we are left with only --enable-cairo-canvas. Note that currently Linux build configuration still has --enable-cairo. See http://cgit.freedesktop.org/libreoffice/core/tree/distro-configs/LibreOfficeLinux.conf#n40 > commit 202557da3c4f1cd57f46a4ba1c9d74e7b4d1c2db > Author: Korrawit Pruegsanusak > Date: Sun Aug 28 15:11:26 2011 +0700 > > Also build cairo on Windows if directx disabled The reason behind this patch is at http://lists.freedesktop.org/archives/libreoffice/2011-August/017228.html Hope this helps :-) Best Regards, -- Korrawit Pruegsanusak ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[REVIEW 3-5] fdo#47326 fix RTF import of mixed super/nonsuper text
Hi,
See
http://cgit.freedesktop.org/libreoffice/core/commit/?id=f84e0e6b1b0ec5f52ee963a62ac420cd872a771e
Regression from 3.4, due to not handling the \nosupersub RTF keyword.
I'm attaching a backport of the patch for -3-5 (plain cherry-pick won't
work as we have no testcases n -3-5).
Thanks,
Miklos
>From f84e0e6b1b0ec5f52ee963a62ac420cd872a771e Mon Sep 17 00:00:00 2001
From: Miklos Vajna
Date: Fri, 23 Mar 2012 12:47:41 +0100
Subject: [PATCH] fdo#47326 fix RTF import of mixed super/nonsuper text
In most cases \super has its own group, but it's valid to have mixed
super and non-super text in a single group, as long as \super and
\nosupersub keywords are used: handle this.
---
writerfilter/source/rtftok/rtfdocumentimpl.cxx |8
3 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/writerfilter/source/rtftok/rtfdocumentimpl.cxx b/writerfilter/source/rtftok/rtfdocumentimpl.cxx
index 84267f3..d378694 100644
--- a/writerfilter/source/rtftok/rtfdocumentimpl.cxx
+++ b/writerfilter/source/rtftok/rtfdocumentimpl.cxx
@@ -1932,6 +1932,14 @@ int RTFDocumentImpl::dispatchFlag(RTFKeyword nKeyword)
m_aStates.top().aCharacterSprms->push_back(make_pair(NS_ooxml::LN_EG_RPrBase_vertAlign, pValue));
}
break;
+case RTF_NOSUPERSUB:
+if (m_pCurrentBuffer == &m_aSuperBuffer)
+{
+replayBuffer(m_aSuperBuffer);
+m_pCurrentBuffer = 0;
+}
+m_aStates.top().aCharacterSprms.erase(NS_ooxml::LN_EG_RPrBase_vertAlign);
+break;
case RTF_LINEPPAGE:
case RTF_LINECONT:
{
--
1.7.7
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Android: java.lang.reflect.UndeclaredThrowableException from com.sun.star.ucb.ContentCreationException: Unable to create Content
The static Reference< XContent > getContent() in
ucbhelper/source/client/content.cxx at line 327ff is called to create
help content, with the xId being
vnd.sun.star.help://?Language=en&System=&Version=${PRODUCTVERSION}.
(Yeah, the ${PRODUCTVERSION} should have been expanded I guess; that
is not the problem here I hope.)
As there is no help (because I don't build any help contents or help
code for Android or iOS, as the help text, and help display concept,
needs to be rewritten / redesigned anyway for these platforms, it
throws a com.sun.star.ucb.ContentCreationException.
I don't see from where exactly it is called (as I haven't built the
calling code for debugging; doing that now, hopefully I guessed
correctly from where it is called): But anyway, in the log I see the
Java message mentioned in the Subject,
java.lang.reflect.UndeclaredThrowableException. I wonder what that
means, anybody have any idea?
Shouldn't this ContentCreationException be caught somewhere in the C++
stack already, so that it never gets out to the Java levels (where
Dalvik then gets upset because it apparently is thrown by something
that doesn't declare throwing such an exception)?
Or is building without xmlhelp doomed to fail at run-time? (I have
made xmlhelp conditional on DESKTOP in the */prj/build.lst files where
it is mentioned.)
--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: minutes of ESC call ...
On Fri, 2012-03-30 at 09:46 +0200, Stephan Bergmann wrote: > For other string constructors, the question is whether there /is/ code > that, say, reads data from a user-supplied document and creates strings > from it, so could be fooled into trying to create excessively large > strings, but also establishes an exception handler that abandons loading > the document. Related to that topic I tried to find and merge the .doc/.xls etc vast collection of custom methods that constructed strings from a stream based on a document provided potentially large count, i.e. read_uInt16s_ToOUString and friends. Those ones now use the (non-memset-0-ing) comphelper::string::rtl_uString_alloc (which I moved out of i18npool or i18nutil or something) and that alternative rtl_uString/rtl_String builder throws on alloc failure. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Modern font features, hacky patch
On Fri, 2012-03-30 at 11:39 +0200, Steve White wrote: > Basic features > == > (Background reading: search for "typographic features", "font feature > registry", "layout tag registry".) > > Some features that really ought to be activated most of the time, in > most scripts > * ligatures for Latin and most alphabetic scripts > * localized replacement (based on text language, region) > * pair kerning > * mark positioning So, I asked Steve to post to the list, so I could dump some experimental code to a wider audience with its context Lets put graphite aside for a moment, its something of a red herring really for a lot of these things. If we look at https://bugs.freedesktop.org/show_bug.cgi?id=31821 I've a patch there that shows that a lot of our woes with otf fonts is probably a simple bug/lack of implementation in out ServerFont::GetTable that it doesn't handle OpenType. freetype does it fine, but we're not using freetype to get the tables, but parsing them outselves. Patch at fdo#31821 a) hacks in using freetype to get the tables (does anyone know if there a freetype api to just get the offset of a table and not a full copy of it ?, we've already mmapped the file so we don't need to copy them) b) hacks in using the icu layout engine for all text, and not just for CTL text. I wonder if its just a performance reason that we have out own "simple" font engine for the non-CTL case ? c) overrides IcuFontFromServerFont::mapCharToGlyph to not filter out the zero width joiner glyphs before applying the gsub table. The icu Indic layout engine doesn't filter it, not sure why the non-Indic ones *do* filter it. So, I reckon we should continue to refactor out font handling code to remove various custom ttf/otf parsing and try and use more of the freetype apis so that LibreOffice gets to know about GSUB etc tables in opentype fonts, and maybe look into removing the simple font layout engine and just use the icu one for all fonts. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: intermittent flaw in gnumake deps on Win32 ..
On Fri, Mar 30, 2012 at 1:05 PM, Matúš Kukan wrote: > On 30 March 2012 11:36, Michael Meeks wrote: >> Regina's problem comes down to a corrupt .d file. >> [...] >> One more data-point, that file was exactly 4096 bytes large: > > What does that mean ? Well - it is either a coincidence, or not.. A multiple of 1024 i.e exactly 4KB in size.. ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Modern font features
Hi Steve, On Fri, Mar 30, 2012 at 11:39 AM, Steve White wrote: > [...] LibreOffice supports many of those, with graphite fonts at least. While you cannot choose most of the features using the regular UI (or rather it is a hidden feature, append ":smcp=1" to a font that supports it and you'll get the smallcaps variant for example), there's an extension that exposes the more fancy features of a font. http://extensions.services.openoffice.org/en/project/typo Typography Toolbar http://numbertext.org/linux/ Graphite enabled Libertine that supports quite a bit of the advanced features. ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Modern font features
On 03/30/2012 11:39 AM, Steve White wrote: * ligatures for Latin and most alphabetic scripts Note that whether or not to use certain ligatures is generally context sensitive. For example in German, "Auflage" should not use an f-l ligature while "flach" should. Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-commits] .: distro-configs/LibreOfficeMinGW.conf distro-configs/LibreOfficeWin32.conf distro-configs/LibreOfficeWin64.conf
On Fri, 2012-03-30 at 08:58 +0200, Stephan Bergmann wrote: > On 03/30/2012 08:51 AM, Stephan Bergmann wrote: > > Looks like this kills MinGW builds > > Ah, looks like Luboš already fixed it, with > e20fa170160e1bb1953ad171e092edfb3de531af. At root there is some *serious* badness that crept in here. I'd really like someone to spend some time to unwind how exactly we managed to screw up our configure.in -so- badly and it remain un-detected for so long. It really needs an expert proctologist to get to the bottom of that; there is a sizeable configure.in change: commit f8d64ffd4a2ee3f6b3340a2bbac21eb7d2b4551c Author: Michael Stahl Date: Mon Nov 7 16:58:52 2011 +0100 configure: refactor system-libs checks: * initialze with_system variables in AC_ARG_WITH * do not interpret --without-system-libs as --with-system-libs I assume you re-configured and diff'd the before/after Host.Env.sh to check nothing changed ? [ but then it was only the Win / Mac builds that changed ]. Or - was this down to the tangle with: commit 202557da3c4f1cd57f46a4ba1c9d74e7b4d1c2db Author: Korrawit Pruegsanusak Date: Sun Aug 28 15:11:26 2011 +0700 Also build cairo on Windows if directx disabled I -hope- that this was related to the VCL / rasterizer_rsvg work and there is no knock-on effect on other configure options / defaults elsewhere :-) Hmm, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: intermittent flaw in gnumake deps on Win32 ..
On 30 March 2012 11:36, Michael Meeks wrote:
> Regina's problem comes down to a corrupt .d file.
>
> Any ideas how that could happen ? are these generated by a pipeline ?
> are we failing to delete them if a compile fails mid-flow ?
They are generated by a pipeline:
$(CXX) ... | filter-showIncludes.pl ; exit
${PIPESTATUS[0]}
> One more data-point, that file was exactly 4096 bytes large:
What does that mean ?
Best,
Matúš
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: intermittent flaw in gnumake deps on Win32 ..
Hi Lubos, Lubos Lunak schrieb: On Friday 30 of March 2012, Michael Meeks wrote: Hi guys, Regina's problem comes down to a corrupt .d file. Any ideas how that could happen ? are these generated by a pipeline ? are we failing to delete them if a compile fails mid-flow ? Then again, Regina didn't abort the build manually, so the ctrl-c-in-mid-flow case is not at issue. Thoughts, Is the problem reproducible? And if yes, does using our own make from contrib help? I don't know if it's related, but I had the stock cygwin make generating broken .d files (although IIRC the problem was generating Windows paths rather than Unix paths). I'm using the LibreOffice patched version of GNU Make 3.82 already. Kind regards Regina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Proposal: Calls for Testing
Hi developers, Hi QAers, On Tue, Mar 27, 2012 at 09:43:21AM +0200, Cor Nouws wrote: > My take on this: > - What does make sense, is having indeed a list of areas that can be > clearly pointed at, and to mention them in a sort of standard post > on our official TDF blog. E.g. every two weeks 4 to 8 items and > guiding users interested to test in these area's to the daily > builds. > This is in the minutes: > > [...] > >AA - propose proactive QA-list CCing on ESC (Bjoern) > > [...] > >AA - Blog regularly about affected areas with call for testing > >(Cor/Bjoern?) lazy me forgot to discuss that action item on the last ESC call (luckily for everyone else, as that call was already too long). So here is what we should do to enable this: Whenever you (developer) have roughly finished working on bugfixing in an area of code or implemented a feature, send a email to both: libreoffice@lists.freedesktop.org libreoffice...@list.freedesktop.org with the subject starting with "[CFT]" (call for testing) and a description of where your changes roughly are. The call for testing is assumed to be for master, unless it says something different. Additional tags might be added to provide more info to the call. Here are some example subjects: [CFT FEATURE] Better UI for Headers and Footers This would be a new feature on master. [CFT 3-5] Copy Paste in Calc This would be bugfixing of the copy paste code for Calc on the 3.5 release branch. You might notice this is a combination of two other ad-hoc workflows we used to get started: the patch review workflow and the UX-advise mailing list to build bridges from development to the outside world. Having written such a mail does not guarantee there will be an army of testers skydiving on the feature, but it will: - lower insecurities in QA when feature is ready to be investigated - give QA a motivation to test master early - be an awesome base for writing our release notes, writing testcases for Litmus (or whatever other tooling we will be using), calls for testing on blogs etc. In fact, unless there is violent disagreement with this, we should just start doing this and see how it goes. ;) Best, Bjoern ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: intermittent flaw in gnumake deps on Win32 ..
On Friday 30 of March 2012, Michael Meeks wrote: > Hi guys, > > Regina's problem comes down to a corrupt .d file. > > Any ideas how that could happen ? are these generated by a pipeline ? > are we failing to delete them if a compile fails mid-flow ? > > Then again, Regina didn't abort the build manually, so the > ctrl-c-in-mid-flow case is not at issue. > > Thoughts, Is the problem reproducible? And if yes, does using our own make from contrib help? I don't know if it's related, but I had the stock cygwin make generating broken .d files (although IIRC the problem was generating Windows paths rather than Unix paths). -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Modern font features
Hi Steve, Thank you for your detailed mail. On Fri, 2012-03-30 at 11:39 +0200, Steve White wrote: > This is to express a general wish, that the word processor be brought > up to date with respect to typographic features This is not a mailing list to express wishes on :-) it's for discussing code, patches, having development questions answered, etc. > It's disappointing that LibreOffice (as well as its commercial > competition) have *poorer* support for these features than the base I agree - but this is (in a nutshell) a reflection of people's willingness to come and hack on the problems. Also, with Graphite2 a number of these features already work rather well AFAIK (but I'm no expert), if you use the right fonts. So - are you willing to help out hacking on this ? you seem to know a good bit about the area :-) if not, that would be disappointing :-) We can help get you up-to-speed here, mentoring new guys is another purpose of this list. All the best, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Modern font features
Feel free to log bugs (preferably with test cases), and preferably one bug per feature. Also feel free to submit patches. It takes a little while to set up a build environment but there are lots of friendly people on this list to help out :-) On 2012-03-30 11:39, Steve White wrote: This is to express a general wish, that the word processor be brought up to date with respect to typographic features, sucha as are present in many modern fonts, and handled by all modern font rendering software. It's disappointing that LibreOffice (as well as its commercial competition) have *poorer* support for these features than the base operating system. That is, a basic text editor, or even a warning dialog box, have better support for font features than a big program designed to handle heavily formatted text! Basic features == (Background reading: search for "typographic features", "font feature registry", "layout tag registry".) Some features that really ought to be activated most of the time, in most scripts * ligatures for Latin and most alphabetic scripts * localized replacement (based on text language, region) * pair kerning * mark positioning Some of these are deactivated for no apparent reason. (Sometimes it's a bug). Finer features == Some features correspond to L/O features, but they aren't properly handled by the font rendering engine. For example * small caps Many fonts contain special glyphs, just for this purpose. Superior applications would first check if the font feature is available and use that, before resorting to a crude scaling. To be fair, the competition doesn't do this either--but XeTeX does (using ICU!!!). It would be *easy* for L/O to beat the competition typographically! Fancier features It would be cool to provide some interface for such features as: * stylistic sets * character variants * user-chosen alternative forms * contextual alternatives * historical forms * petite caps (and other capitalization-related features) * old-style or proportional digits * fractions * swashes The new Millennium = While current "desktop publishing" software is stuck in the 80s typographically, web browsers are catching up to the font standards. (Especially considering that some people use desktop publishing software to generate web pages!) There are already proposals to give control of such features to web page developers. http://www.w3.org/TR/css3-fonts/#font-variant-ligatures-prop http://opentype.info/blog/2010/08/14/better-web-typography-with-opentype-features/ https://developer.mozilla.org/en/CSS/-moz-font-feature-settings http://ie.microsoft.com/testdrive/Graphics/opentype/opentype-fontbureau/index.html http://blogs.adobe.com/typblography/2010/09/opentype-features-come-to-the-web.html Here is an interesting chart of typographic features vs applications. http://www.typotheque.com/fonts/opentype_feature_support (OpenOffice.org isn't on the list, for good reason, I think.) (it says Word does small caps -- but it doesn't do them right) Compatibility = Of course there's the argument that LibreOffice should be just as bad as the competition. (As though at some point LibreOffice ever produced documents that were identical with the competition's. As though the competition displayed documents identically on different systems -- of course the real world was never this way!) But to fill a desire for cozy similarity with the competition, there is always the always the option of a compatibility flag, to excise any excellence. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Modern font features
This is to express a general wish, that the word processor be brought up to date with respect to typographic features, sucha as are present in many modern fonts, and handled by all modern font rendering software. It's disappointing that LibreOffice (as well as its commercial competition) have *poorer* support for these features than the base operating system. That is, a basic text editor, or even a warning dialog box, have better support for font features than a big program designed to handle heavily formatted text! Basic features == (Background reading: search for "typographic features", "font feature registry", "layout tag registry".) Some features that really ought to be activated most of the time, in most scripts * ligatures for Latin and most alphabetic scripts * localized replacement (based on text language, region) * pair kerning * mark positioning Some of these are deactivated for no apparent reason. (Sometimes it's a bug). Finer features == Some features correspond to L/O features, but they aren't properly handled by the font rendering engine. For example * small caps Many fonts contain special glyphs, just for this purpose. Superior applications would first check if the font feature is available and use that, before resorting to a crude scaling. To be fair, the competition doesn't do this either--but XeTeX does (using ICU!!!). It would be *easy* for L/O to beat the competition typographically! Fancier features It would be cool to provide some interface for such features as: * stylistic sets * character variants * user-chosen alternative forms * contextual alternatives * historical forms * petite caps (and other capitalization-related features) * old-style or proportional digits * fractions * swashes The new Millennium = While current "desktop publishing" software is stuck in the 80s typographically, web browsers are catching up to the font standards. (Especially considering that some people use desktop publishing software to generate web pages!) There are already proposals to give control of such features to web page developers. http://www.w3.org/TR/css3-fonts/#font-variant-ligatures-prop http://opentype.info/blog/2010/08/14/better-web-typography-with-opentype-features/ https://developer.mozilla.org/en/CSS/-moz-font-feature-settings http://ie.microsoft.com/testdrive/Graphics/opentype/opentype-fontbureau/index.html http://blogs.adobe.com/typblography/2010/09/opentype-features-come-to-the-web.html Here is an interesting chart of typographic features vs applications. http://www.typotheque.com/fonts/opentype_feature_support (OpenOffice.org isn't on the list, for good reason, I think.) (it says Word does small caps -- but it doesn't do them right) Compatibility = Of course there's the argument that LibreOffice should be just as bad as the competition. (As though at some point LibreOffice ever produced documents that were identical with the competition's. As though the competition displayed documents identically on different systems -- of course the real world was never this way!) But to fill a desire for cozy similarity with the competition, there is always the always the option of a compatibility flag, to excise any excellence. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: intermittent flaw in gnumake deps on Win32 ..
On Fri, 2012-03-30 at 10:36 +0100, Michael Meeks wrote: > Regina's problem comes down to a corrupt .d file. One more data-point, that file was exactly 4096 bytes large: > >/cygdrive/c/PROGRA~1/MICROS~1.0/VC/include/new \ > >/c [EOF] :-) Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
intermittent flaw in gnumake deps on Win32 ..
Hi guys, Regina's problem comes down to a corrupt .d file. Any ideas how that could happen ? are these generated by a pipeline ? are we failing to delete them if a compile fails mid-flow ? Then again, Regina didn't abort the build manually, so the ctrl-c-in-mid-flow case is not at issue. Thoughts, Michael. On Fri, 2012-03-30 at 11:30 +0200, Regina Henschel wrote: > workdir/wntmsci12/Dep/CxxObject/extensions/source/propctrlr/browserlistbox.d > > looks bad, I see >/cygdrive/c/PROGRA~1/MICROS~1.0/VC/include/stdexcept \ >/cygdrive/c/PROGRA~1/MICROS~1.0/VC/include/exception \ >/cygdrive/c/PROGRA~1/MICROS~1.0/VC/include/xstddef \ >/cygdrive/c/PROGRA~1/MICROS~1.0/VC/include/cstddef \ >/cygdrive/c/PROGRA~1/MICROS~1.0/VC/include/eh.h \ >/cygdrive/c/PROGRA~1/MICROS~1.0/VC/include/malloc.h \ >/cygdrive/c/PROGRA~1/MICROS~1.0/VC/include/xstring \ >/cygdrive/c/PROGRA~1/MICROS~1.0/VC/include/xmemory \ >/cygdrive/c/PROGRA~1/MICROS~1.0/VC/include/new \ >/c > > workdir/wntmsci12/Dep/LinkTarget/Library/ipcr.lib.d > looks good, I see >/cygdrive/c/PROGRA~1/MICROS~1.0/VC/include/ymath.h \ >/cygdrive/c/PROGRA~1/MICROS~1.0/VC/include/cfloat \ >/cygdrive/c/PROGRA~1/MICROS~1.0/VC/include/cmath > > /cygdrive/c/git/LO36APR/solver/wntmsci12/inc/offapi/com/sun/star/xsd/WhiteSpaceTreatment.hdl: > > /cygdrive/c/git/LO36APR/solver/wntmsci12/inc/offapi/com/sun/star/xsd/WhiteSpaceTreatment.hpp: > > /cygdrive/c/git/lo36apr/extensions/source/propctrlr/xsdvalidationpropertyhandler.hxx: -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Bug 37361] LibreOffice 3.5 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=37361 sasha.libreoff...@gmail.com changed: What|Removed |Added Depends on||48081 -- 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
[Bug 37361] LibreOffice 3.5 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=37361 --- Comment #257 from sasha.libreoff...@gmail.com 2012-03-30 02:29:04 PDT --- Linux specific regression: Bug 48081 - Impress UI: impossible to select picture using left mouse click -- 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
Re: Build breaks, likely somewhere in linking
> Quite possibly either the gcc generation of these, or the concatenation > of them is not as robust as it could be Yeah, I used to see lots of these screwed up .d files, too. (Either oddly truncated, or looking as if several simultaneous processes had written to the same .d file.) Never understood the root cause. For some reason I have not been seeing them lately, that could be because I am now using our own make 3.82, or because I don't really build that often on Windows any more. Or then I have just been lucky. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Build breaks, likely somewhere in linking
On Fri, 2012-03-30 at 01:11 +0200, Matúš Kukan wrote: > On 29 March 2012 22:56, Regina Henschel wrote: > > build breaks, I have attached the build_error.log. I have run "make build" > > twice to make sure, that it not a simple timing problem. > > make[1]: *** No rule to make target `/c', needed by > `/cygdrive/c/git/LO36APR/workdir/wntmsci12/CxxObject/extensions/source/propctrlr/browserlistbox.o'. > Stop. > does not look good. I can't imagine where /c came from. So - I -think- /c is a truncated /cygdrive/... probably from a generated .d dependency file. Quite possibly either the gcc generation of these, or the concatenation of them is not as robust as it could be to being aborted mid-flow (you have enough free disk-space right ? :-). Anyhow - if we can chase that down: grep -R browserlistbox.o core/workdir might give some a handful of hits, and by running 'tail' on them all you could see whether they are truncated perhaps ? if that is the case we can dig in the gnumake dependency rules and/or the deps simplifier / concatenator to see if that is the problem. Thanks ! Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Bug 37361] LibreOffice 3.5 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=37361 Michael Meeks changed: What|Removed |Added Depends on||43009 -- 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
Re: [PUSHED] Fix for Bug 43895: Never let users save in /tmp by default
On 27/03/12 13:30, Bjoern Michaelsen wrote: On Tue, Mar 27, 2012 at 01:20:27AM +0200, Bjoern Michaelsen wrote: Patch looking good -- I will apply, test and push tomorrow(*). Pushed as: http://cgit.freedesktop.org/libreoffice/core/commit/?id=dd2fe95cce75f1157bd1c75d286a0047b2e4175e Twaeking according to Stephans comments. Best, Bjoern ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice I was just testing under Windows today -- firefox does the same there (I believe IE also lets you do this -- didn't think about testing though while I was under windows), with the only difference being the tmp directory used to store a file in. I think fixing it for windows will involve changing the directory checking line -- I'll look into this when I finish the current bug I'm working on. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Source tree location hint for writer table issue?
Hi David,
On Thu, 2012-03-29 at 17:49 -0400, David Bolen wrote:
> I was wondering if someone more familiar with the source tree layout
> than I am might be able to offer a hint as to where I should be
> looking for something?
>
> I'm trying to investigate an issue with tables (in Writer) that showed
> up when I auto-generated a table, where selecting the table as a whole
> shows "read-only" in the status bar and you can't do anything with it
> (and about the only way to get rid of it is to select a single cell
> and then use Table -> Delete -> Table from the menu). Nothing about
> the table or any of its cells were actually protected in any way
> during generation. I don't think it's an open issue though it's tough
> to search for given all the cell and row/column protection related
> discussions, but very little for the table as a whole.
For the Read-only problem, you should have a look at
SwPaM::HasReadonlySel(): this checks if the selection is read-only or
not.
> Anyway, I've been feeling a bit like was back playing Adventure ("You
> are in a maze of twisty little passages, all alike") attempting to
> deduce where the table status might be getting determined (and even
> back-tracking the "read-only" status bar string), and was wondering if
> anyone with past experience with the table code might be able to give
> me a nudge in a general direction in terms of the source tree?
Hopefuly, there are ways to cheat to get out of the maze... and you
found one :)
--
Cedric
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: minutes of ESC call ...
On Thu, 2012-03-29 at 21:41 +0200, Tommy wrote: > > * Pending Action Items > > + [well underway] review and re-close 3.4.x MAB fixed in 3.5.x (Rainer) > > snip > > "MAB = most annoying bugs" is a registered trademark by Tommy Lol :-) > however I'm gonna let you use it under LGPLv3+/GPLv3+/MPL licences :-) Thanks ! good to have you around :-) and thanks for your work on bugs ! :-) Incidentally, if you have more spare cycles to help out with bug triage it'd be much appreciated - the quicker we can get bugs from UNCONFIRMED into a reproduced / de-duplicated state and prioritised well the faster we can fix the truly most annoying :-) Anyhow, good stuff :-) Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[REVOKED][REVIEW]46901 slideshow uses cairo on Windows
>It appears that fdo46901 has been fixed and pushed for 3.5.3. >I would very much appreciate it if it could be pushed to 3.5.2 as well, as it >is a blocker as far as our company is concerned. >(don't know if the nessage header contains the correct tags) Oops, I just found out that it has been pushed to 3.5.2RC2, that is, the problem is no longer there : ) I was misled by the comment in fdo 46901, which said that it will be available in 3.5.3. Sorry for the confusion and thnaks for the fix :-) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [REVIEW]46901 slideshow uses cairo on Windows
The currently release 3.5.2rc2 has the fix. Only that I disabled the cairo canvas in configure options there in order to avoid a need of respinning the whole rc3 just because of this. If you download 3.5.2rc2, you will be happy :) F. On 30/03/12 09:14, Winfried Donkers wrote: > Hi, > It appears that fdo46901 has been fixed and pushed for 3.5.3. > I would very much appreciate it if it could be pushed to 3.5.2 as well, > as it is a blocker as far as our company is concerned. > (don't know if the nessage header contains the correct tags) > Winfried > ___ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: minutes of ESC call ...
On 03/29/2012 06:46 PM, Michael Meeks wrote: * exception size stats (Caolan) + likes exceptions, but they are big + trade-off - bigger tables for smaller code ? + new constructors in 3.6 - work on string literals + shouldn't have to throw - small strings + not strings controlled by malicious input (Stephan) + we abort anyway in these cases AA: + drop exception specs from new string constructors (Lubos) + drop from Any / small object allocations as interested Just to clarify: The decision whether to trade "throw std::bad_alloc" for "std::abort()" should be based on whether calling code wants to handle the out-of-memory situation (i.e., catch the bad_alloc). For Lubos' new string-from-literal constructors, the case is pretty clear: If such strings cannot be allocated, memory has run so low that the application cannot meaningfully operate any longer, anyway. For other string constructors, the question is whether there /is/ code that, say, reads data from a user-supplied document and creates strings from it, so could be fooled into trying to create excessively large strings, but also establishes an exception handler that abandons loading the document. What I wanted to say on the call is that /if/ there is no such code anyway, then we can probably turn existing "throw std::bad_alloc" into "std::abort()" without loss of functionality (but with a gain in reducing object size). Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Source tree location hint for writer table issue?
On Thu, Mar 29, 2012 at 05:49:53PM -0400, David Bolen
wrote:
> Anyway, I've been feeling a bit like was back playing Adventure ("You
> are in a maze of twisty little passages, all alike") attempting to
> deduce where the table status might be getting determined (and even
> back-tracking the "read-only" status bar string), and was wondering if
> anyone with past experience with the table code might be able to give
> me a nudge in a general direction in terms of the source tree?
Hi David,
Not that I'm a table expert, but here is where I would start:
http://wiki.services.openoffice.org/wiki/Writer/Core_And_Layout#Tables
Miklos
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[REVIEW]46901 slideshow uses cairo on Windows
Hi, It appears that fdo46901 has been fixed and pushed for 3.5.3. I would very much appreciate it if it could be pushed to 3.5.2 as well, as it is a blocker as far as our company is concerned. (don't know if the nessage header contains the correct tags) Winfried ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
build failure: sc_ucalc.test - cppunittester abort trap (core dumped)
[I tried at the users list but was advised I should post here instead] Hi, I'm new here, and I'm driven here by desperation. I'm trying to build libreoffice-3.4.5.2 on FreeBSD and it is failing the testing stage. I'm running out of time for a client to pick up, so I need to fix this now and I need some pointers on how to figure out whats wrong here. This is on a unit not on the network, so this output has been copied by hand: Module 'scripting' delivered successfully. 0 files copied, 28 files unchanged gb_LinkTarget_add_library_objects,CppunitTest/libtest_sc_ucalc.so,Library/libscfb.so gb_LinkTarget_add_linktarget_objects,CppunitTest/libtest_sc_ucalc.so,Library/libscfb.so [ build ALL ] top level modules: sc [ build ALL ] loaded modules: sc [ build CUT ] sc_ucalc Abort trap (core dumped) terminate called after throwing an instance of 'com::sun::star::uno::RuntimeException' gmake[1]: *** [/usr/ports/editors/libreoffice/work/libreoffice-bootstrap-3.4.5.2/solver/340/unxfbsd.pro/workdir/CppunitTest/sc_ucalc.test] Error 1 dmake: Error code 2, while making 'all' [ build ALL ] top level modules: sw [ build ALL ] loaded modules: sw [ build CHK ] loaded modules: sw [ build LOG ] sw sw deliver deliver -- version: 275594 Module 'sw' delivered successfully. 0 files copied, 1 files unchanged - [build error message] internal build errors: ERROR: error 65280 occurred while making /usr/ports/editors/libreoffice/work/libreoffice-bootstrap-3.4.5.2/sd/qa/unit ERROR: error 65280 occurred while making /usr/ports/editors/libreoffice/work/libreoffice-bootstrap-3.4.5.2/sc/prj [ standard fix message ] rm -Rf /usr/ports/editors/libreoffice/work/libreoffice-bootstrap-3.4.5.2/sd/unxfbsd.pro # optional module 'clean' /usr/local/bin/bash cd /usr/ports/editors/libreoffice/work/libreoffice-bootstrap-3.4.5.2 source ./FreeBSDAMDEnv.Set.sh cd sd build So I follow the instructions and under "start unit test #1 on library ../../unxfbsd.pro/lib/libqa_unit.so": terminate called after throwing an instance of 'com::sun::star::uno::RuntimeException' /usr/local/bin/bash: line 1: 70633 Abort trap: 6 (core dumped) [ more data output (remember I'm copying by hand) ] dmake: Error code 134, while making 'test' --- [ standard error message - again ] internal build errors: ERROR: error 65280 occurred while making /usr/ports/editors/libreoffice/work/libreoffice-bootstrap-3.4.5.2/sd/qa/unit it seems that the error is inside 'sd', please rerun build inside this module to isolate the error and/or test your fix: --- [ standard fix message - again ] This is all very well, but I have no idea where to go from here. I tried examining the core dumps (when I found them), but all I get is: #0 0x0008016bca7c in ?? I cannot get anymore information to help debug the problem. I ran make with -DDISABLE_MAKE_JOBS and -DDEBUGCPPUNIT to no avail. I checked if $LANG and friends are set - no. What pagan ritual do I need to perform to find out whats wrong? Or better yet - whats wrong? Cheers ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
