I see that a solution is/was targeted for version 3.5. As of yesterday, that
had not yet been achieved (the problem still persists with 3.5 and code from
yesterday).
The problem is quite annoying for users (such as in our company).
Does anyone know (Kohei Yoshida?) the current status of the
Hello all,
I started translating from German to English in sc/source/ui/view and I hope to
start sending in my contributions soon.
Winfried
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
First tiny contribution.
Translated comments, also renamed define MAX_COL_HEIGHT to MAX_ROW_HEIGHT.
This patch is and future patches will be contributed under the LGPLv3+ / MPL.
By the way,
should comments like
case FID_INS_COLUMN:// insert columns
case
(reply to list as well is better, of course)
First tiny contribution.
Translated comments, also renamed define MAX_COL_HEIGHT to MAX_ROW_HEIGHT.
Erm, I think the attached patch is not the intended one right ( patch attached
is something already committed )?
I did it with 'git commit -a'
Finally can you confirm you contribution is under LGPLv3+ / MPL license
My contribution and future contribution is under LGPLv3+/MPL license.
Winfried
thanks again,
Noel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
How do I update my local sources to the current (latest) master with git?
I am not familiar with git, have used 'git clone' and 'git diff', but I don't
want to do 'git clone' again, of course.
Is 'git checkout' the proper way (run from the directory where .git is)?
I have some more
(sc/source/ui/view) and then I
hope to find an easy hack in C++ (but all at a leisurely pace...).
Winfried
-Original Message-
From: Michael Meeks [mailto:michael.me...@suse.com]
Sent: maandag 14 november 2011 13:24
To: Winfried Donkers
Cc: libreoffice@lists.freedesktop.org
Subject: Re
Some more translations for sc/source/ui/view.
This and future contributions submitted under LGPL3+ ? MPL.
Winfried
0001-translations-of-comments-from-german-to-english.patch
Description: 0001-translations-of-comments-from-german-to-english.patch
I've just changed the translation of
// Targets am SBA abmelden nicht mehr noetig
to
// unregistering target in SBA no longer necessary
Sorry, I must have read anmelden instead of abmelden. Thank you for being
critical:)
Winfried
___
LibreOffice
Some more translated files.
This and subsequent contributions submitted under LGPL3+ / MPL.
Winfried
0001-german-comments-translated-to-english.patch
Description: 0001-german-comments-translated-to-english.patch
___
LibreOffice mailing list
Hello all,
This bug (MS Access databases cannot be opened since LibO 3.4) is a serious
problem for several cpmpanies that migrated from MS Office to LibO (including
the company I work for).
Comment 11 from Alex Thurgood gives a possible cause, but:
-I am not familiar with the make system of
This bug (MS Access databases cannot be opened since LibO 3.4) is a serious
problem for several cpmpanies that migrated from MS Office to LibO
(including the company I work for).
Comment 11 from Alex Thurgood gives a possible cause, but:
-I am not familiar with the make system of LibO;
-I am
PUSHED with some minor changes, I just tweaked some spelling and rephrased
something here and there as I scanned the translations, since I don't speak
German I have no idea how accurate the translations are :-) but they seemed
to make mostly sense to me :-)))
As neither German nor English is my
for building LibreOffice. It'll take
some time, but when I succeed I will get back to you with feedback (or
questions).
Winfried Donkers
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Excellent. Feel free to ask for help if you get stuck setting it up.
-- Noel Grandin
I have installed all dependancies (I hope) and am now trying to get
./autogen.sh to succeed (so far, a lot of paths to be set as option). I keep
having trouble with moz/zipped. Should this be (as seen from
Excellent. Feel free to ask for help if you get stuck setting it up.
-- Noel Grandin
.autogen.sh succeeded, now make give a strange error:
...
configure: creating ./config.status
./configure: line 8411: test: too many arguments
./configure: line 8411: test: too many arguments
./configure: line
Looking at the LibreOffice project's interest, in the short term we
would probably benefit more from your going through other
EasyHacks. Except if it makes the difference between having the fix
for 3.4.5 or not, but I dare hope the Windows build will be fixed
soon enough for that not to be a
.autogen.sh succeeded, now make give a strange error:
...
configure: creating ./config.status
./configure: line 8411: test: too many arguments
...
configure: error: could not make ./config.status
...
Hmmm, that looks like a quoting problem with the $CPP variable.
What does your $CPP
Dear Bjoern,
You made bug 34425 an easy hack; I would like to give it a try, but can you
give me a hint where I can find the relevant code for these buttons (in scalc
and swriter)?
I have tried t find them before, but so far no success.
Winfried
This looks like a incompatibility between autoconf-generated boilerplate
code and your environment.
Check that configure has been regenerated;
it should says at approx line 3:
Generated by GNU Autoconf 2.6x with 2.6x being the version of autoconf you
installed;
It says now Generated by GNU
So, just to check I understand right, when you say the error messages are the
same with different line numbers, it means the following?
The rror messages are
configure: creating ./config,status
./configure: line 6255: test: too many arguments (6 identical lines)
configure: error: could not make
So it does *not* output:
File STDIN: 5 lines match
No, it did not.
Then I think you (from your shell) and ./configure use a different grep, and
the grep that ./dmake/configure uses behaves differently than expected:
configure expects that grep -c FOO outputs JUST the number, but the grep it
I am trying to locate the source where the page size is determined when
creating a new label document with the wizard.
Although the dimensions in the label-definitions for A4 label sheets are
correct, LibO creates a document with custom page format and not A4.
I can't find where the document is
Attached is a patch for bug 36874. It also patches bugs 34271, 35104, 35272 and
41755 which IMHO are duplicates.
The old calculaton of page size during the creation of a new document was
incorrect, leading to misalignment when printing.
I have replaced it with a better (I think) calculation and
Attached is a patch for bug 36874. It also patches bugs 34271, 35104, 35272
and 41755 which IMHO are duplicates.
The old calculaton of page size during the creation of a new document was
incorrect, leading to misalignment when printing.
I have replaced it with a better (I think) calculation
Hello all,
I have just got a new computer, which should make LibO much faster than my old
machine does :) .
Unfortunately, I get a make error:
.../core/solver/unxlngi6.pro/bin/cppunit/cppunittester: symbol lookup error:
/usr/lib/gtk-2.0/2.10.0/engines/liboxygen-gtk.so: undefined symbol:
Looks like a symbol conflict between your internal cairo library and
the system gtk+ library. Curious that it happens with the cppunit test
of course. Essentially I would remove *cairo* from the solver (or run
deliver -delete inside cairo/) and re-configure and build with
--with-system-cairo.
last week my patch for bug 36874 (wrong paper size with labels in writer) was
pushed.
It also patches bugs 34271, 35104, 35272 and 41755 which IMHO are duplicates of
36874.
These can be closed, (a little bit of cleaning up the bugs :) )
Winfried
___
Hi Rainer,
thx for the hint, I will test soon and close. Can you please check
whether the fix also is in the 3.5 Beta1 Branch?
I downloaded from daily builds (Win-x86@7-MinGW) on a Windows XP machine:
- 3.5.0beta1 2011-12-13_03.17.52 gave an error wehen starting soffice.exe or
swriter.exe:
Is it an option to push it to 3.4.5 as well?
I think it should be pushed also for 3.4.5, but I'm not familiar with
the rules. And may be some users have become used to tricks living with
the old formats, and a change would cause trouble for them?
The trick I was advised to use was to manually
Is it an option to push it to 3.4.5 as well?
In case you haven't known this yet: if you want to do this, you have
to send a mail to this dev list with a subject like
[REVIEW] $subject
and pointing to your commit. Then wait for someone to review.
This probably is still not the correct way to
Your code looks definitely better than the original one. Well, I am
still not sure about the calculation. It makes perfect sense when I
imagine the paper with blank labels. On the other hand,
please look at http://download.go-oo.org/tmp/labels.png.
I looked at a lot of (blank) labels and also
(See bug 36874 (and this list) for history)
It would be much better if the label-definitions contain all dimensions, i.e.
should include either right margin and bottom margin or the page size.
The visualization is crazy. It would be great to fix it.
For users, label printing is mostly
I often get a failed make dev_install when building following a git pull
--rebase.
The error is that dict-xx.oxt (today they were dict-an.oxt, dict-be.oxt,
dict-el.oxt, dict-gd.oxt, dict-si.oxt and dict-te.oxt) files cannot be found.
This occurred also after a clean git clone on a new machine.
Hi Ivan,
Ivan, what do you think? Are you interested?
Interested, but extremely busy the whole January through... :-(
I'm sorry. But an UI is an easy piece of programming; Winfried, may be
you need a few little tips to start, and then there will be no
questions? If so, please ask on using the
The error is that dict-xx.oxt (today they were dict-an.oxt, dict-be.oxt,
dict-el.oxt, dict-gd.oxt, dict-si.oxt and dict-te.oxt) files cannot be found.
I think running git pull -r in core/dictionaries should fix this.
Thanks, it helped.
Still strange that git pull -r from core doesn't/didn't
My calculation is based on the assumption (presumption?) that the
page containing the labels is symmetrical, i.e. rotating the page
180 degrees is not a problem, left margine equals right margin and
top margin equals bottom margin.
some labels paper that I bought last year (I guess of too bad
Still strange that git pull -r from core doesn't/didn't help. That's what I
do to update my sources.
Do a ./g pull -r in core instead. It calls git pull -r in all the
sub-repos underneath core/clone/ (and in core itself, of course).
Thank you. I will do ./g instead of git in the future and
Hi,
There are some bugs in calc that damage formulas/conditional formats of cells.
As this goes further than just being a nuisance I would like to nominate them
for solving with high(er) priority.
But I don't want to make things worse and I don't want to annoy people who are
already working
some labels paper that I bought last year were not symmetric
I found that too when I started to extend the label defintions (1700+ ...) in
labels.xcu with paper height and paper width.
And also that by rounding off the calculated paper size can differ +/- 2mm
from the actual size,
So if Winfried prefers to document choices in the bug to feel safe, I dont
think that is objectable (without that being a hard requirement, of course).
Thank you for all your advice.
I have created bug 44516 and will document the process there.
I leave to you wise men to adjust all the sensitive
Hi,
I am adding sheet-dimensions to the label-definitions (Labels.xcu) used in
label wizard and business card wizard.
Of the 1790 definitions, there are now only 199 to be checked. Unfortunately,
these can only be checked manually : (
Some labels on pinfeed sheets are discontinued, no longer
Another thing that interests me is that parsing the configuration,
despite all Stephan's good work in configmgr to speed it up, still takes
real time and space: say 4% of our startup and a chunk of RAM. If we
look at the sizes of our config using a simple:
As the contents of Labels.xcu
What do you mean with The current format does not look efficient to
me. Efficient in terms of what?
Just that the file size caused by the xml-tags exceeds the file size
caused by the data itself. I have nothing against xml and I am no expert.
For me there is no need to change it, it's purely
Hi,
When you create a new label-document, say a label form (paper size A4) with 3
columns and labels of 70mm wide (no gap between them), the result is a
distorted document (If you want to reproduce take label Tower-CIL-W100 of Avery
Zweckform-3422). It is mentioned in bug 35104 and concerns
This is caused by MM100 to TWIP conversion. An A4 page is 210mm,
11906twip. The calculated document width is 210mm, 11907twip.
Do you know where the code is that calculates 11907 as the result ?
No. I know that:
-a macro (MM100_TO_TWIP) is used.
-the paper width is calculated from (leftMargin
Attached the patch for fdo34425.
Also, I translated the german comments in tbcontrl.hxx (plus corrected one
typing error in it)
WinfriedFrom edc9e766596ca7ef1d297e285a948ac05d03b994 Mon Sep 17 00:00:00 2001
From: Winfried Donkers o...@dci-electronics.nl
Date: Sat, 21 Jan 2012 11:34:26 +0100
Info Agipa wrote (27 juli 2012 09:28)
Hi Sylvain,
How is the best way to perform this ?
There is a description of this file to give the good informations ?
See:
officecfg/registry/data/org/openoffice/Office/Labels.xcu
Winfried did some lovely work recently to
Hi Eike,
All your comments have been processed in the code (I learned some new
things too, thank you !).
It now works fine for all possible argument values, including leaving out the
optional value for WEEKNUM and illegal arguments.
Now I will start on seeing how old-style documents are
Van: Eike Rathke [mailto:er...@redhat.com]
Verzonden: donderdag 24 mei 2012 01:44
From the Small Group, all but AVERAGIF are available.
I wil keep from AVERAGEIF (and fdo 41214), as communicated in the bug.
From the Medium Group, at least ISOWEEKNUM seems to be missing in calc.
I'm still
Hi,
Whilst working on function ISOWEEKNUM (fdo 50488), I found that function
WEEKNUM has a different behaviour as defined in ODFF1.2.
The difference is in interpreting parameter Mode:
ODF1.2 states:
(default value for Mode = 1)
Constraints: 1 ≤ Mode ≤ 2, or 11 ≤ Mode ≤ 17, or Mode = 21, or
61d133beff3ce513dbeb0df82453f3b9a780518b Mon Sep 17 00:00:00 2001
From: Winfried Donkers o...@dci-electronics.nl
Date: Wed, 9 May 2012 16:47:13 +0200
Subject: [PATCH] fdo#44456 added calc function DATEDIF as in ODF1.2
Change-Id: I082ea20d02bf37d515fc33d627281696fc48fcb6
---
formula/inc/formula/compiler.hrc |7
Hi Eike,
Argh, I missed to reply to you in the bug that XOR is also in the said CWS we
still hope to be able to integrate back from OOo times. So you duplicated
some work, my bad. Anyway, if it's ready we'll integrate it, adding some
pieces for Excel import/export. However, you attached a
Hi Eike,
I would like to change the behaviour of function WEEKNUM to conform to
ODFF1.2 [...]
We might
get away with strictly complying with ODFF and generate an error for
constraint cases if prominently mentioned in release notes that WEEKNUM
changed. Users will have to change formulas
Hi Eike,
I think this might be a plan:
* enhance WEEKNUM_ADD to support all ODF WEEKNUM modes
* in the UI rename WEEKNUM to ISOWEEKNUM
* change ISOWEEKNUM to accept only one parameter
* during import's formula compile step for ISOWEEKNUM check if a second
argument is provided
* if so
.
Winfried
From 45326af955b020cc861148c7c1c95449dab858f4 Mon Sep 17 00:00:00 2001
From: Winfried Donkers o...@dci-electronics.nl
Date: Wed, 6 Jun 2012 16:33:38 +0200
Subject: [PATCH] fdo#50488 added calc formula XOR as in ODFF1.2
Change-Id: I89c3267d479d5f034ad25ff879d1df8f90b84a55
---
formula/inc/formula
Hi Eike,
Great we agree :)
Yes, isn't it :)
Note that UI names may (and sometimes do) differ from ODF file format
names, the relation is
UI WEEKNUM == ODF ISOWEEKNUM
UI WEEKNUM_ADD == ODF WEEKNUM
see also formula/source/core/resource/core_resource.src
Resource
Hi Eike,
Huh? Accidentally hit the delete line key in your editor?
No, I did a git pull -r whilst working on the code and forgot to update this
file. Should have seen it, though.
Using a short here and incrementing it for values!=0 may easily overflow
if ranges are passed. A better approach
:00:00 2001
From: Winfried Donkers o...@dci-electronics.nl
Date: Sat, 9 Jun 2012 12:43:30 +0200
Subject: [PATCH] fdo#50822 add function XOR to calc as in ODFF1.2
Change-Id: I994119c0520658775d07f776237d31a03f53ab52
---
formula/inc/formula/compiler.hrc |5 +-
formula/inc/formula
Hi Eike,
I just uploaded a diff file and test document to bug50950.
The ODFF1.2-compliant functions work and I would like some help from you with
importing old-style formulas from documents saved with previous LibO versions.
Your plan from June 7 (see below) seems clear to me, but I don't know
Still, this removes the comments from many people's (potential) sight.
The IMO big advantage of the everything on a single mailing list
approach is that everybody is forced ;) to see everything (modulo
information overload)
So, IMHO that advantage not only has its drawbacks (information
Hi Eike,
Please see my Splinter review in
https://bugs.freedesktop.org/show_bug.cgi?id=50950#c3
I will do that. (I hope my contributions don't cost you too much time in
correcting so that they fit well in the general picture...)
It seems one point didn't make it across: I did not suggest
Well, my hope is that I'm not too dumb to educate you ;-) so you'd be
able to work more independently on spreadsheet functions.
It's more the question if I am smart enough to pick up the essentials of LibO
spreadsheet functions quick enough ;-)
Anyway, I improved my patch and did learn from
Hi Noel,
$ git grep -n WEEKNUM_ADD
sc/source/core/tool/odffmap.cxx:38:{ WEEKNUM, WEEKNUM_ADD,
false, com.sun.star
Thank you for your suggestion.
That line has been changed in my patch to ...{ WEEKNUM, WEEKNUM, ...
And that's why I am at a loss
Winfried
Hi Eike,
Please see my splinter review in
https://bugs.freedesktop.org/show_bug.cgi?id=50950#c6
All your comments have been processed in the code (I learned some new things
too, thank you !).
It now works fine for all possible argument values, including levibng out the
optional value for
After a ./g pull -r and a clean build of master, both my machines instantly
produce an error when I try to run LibreOffice:
on one machine (openSUSE 11.4):
warn:desktop:22640:1:/home/w.donkers/git/libo/desktop/source/app/app.cxx:702:
UNO Exception: InvalidRegistryException:
What should I do to to solve this?
First, please tell me the current head of your core repo. You
observed this problem the first time when you ran exactly this LO version,
right?
must look up how to get that :/
Short answer: remove ~/.config/libreoffice/3/user/extensions/bundled/
(the
First, please tell me the current head of your core repo. You
observed this problem the first time when you ran exactly this LO version,
right?
commit f839984910f0fd4ef385552df3af5e09190e15b9
(the other machine is at home, that will be different by some hours)
Winfried
commit f839984910f0fd4ef385552df3af5e09190e15b9
Is the above on the openSUSE 11.4 machine (reporting a problem with
org.openoffice.pyuno.LanguageScriptProviderForPython)?
Yes it is. Sorry for not mentioning.
So, if commit f839984910f0fd4ef385552df3af5e09190e15b9 is for openSUSE
11.4, and
Hi,
I have added the formula 'datedif', as defined in ODF 1.2 to calc (see diff).
But there are some items I would like to get advise on:
1. parameter fmt in datedif( date1; date2; fmt ) defines the output (d, m, y,
yd, ym, md for days, months etc). In my code, the users needs to enter d
(i.e.
If you already ran into the problem, git pull make will not automatically
make it go away; you'll need to manually remove
~/.config/libreoffice/3/user/extensions/bundled/ once.
Hence, I'll still like to know the current head on that machine, before you do
a fresh git pull. (And the
Yay, that is from before my fix. So my theory that the problem should
be solved by now is not yet proven wrong.
Congratulations :)
at the second attempt is odd (unless you explicitly start soffice.bin
instead of soffice)
I did
Winfried
___
@Eike and @Regina:
Thank you for your reactions.
Unfortunately I have to be absent for a couple of days, so I cannot respond to
you, nor put your advises/suggenstions into the code yet.
But I will get back to you and make the enhancement fit to submit :-)
Winfried
Attached diff is NOT intended to be pushed at this state.
I have added the formula 'datedif', as defined in ODF 1.2 to calc (see diff).
Hey, great!
2. the calculation in DateDif(..) uses mean values for days in year
(365.2425) and for days in month (30.4369). That will in some
instances
The function originates from Lotus 1-2-3 where it was called DATEDIF,
MS-Excel called it the same, and ODF just adopted that name. The
DATEDIFF function you mention is something different (VBA?).
I don't know if the function needs to be added to xlformula.cxx and/or
lotform.cxx (see
Van: Kohei Yoshida [mailto:kohei.yosh...@gmail.com]
Verzonden: dinsdag 8 mei 2012 21:00
Once the xlformula.cxx/lotform.cxx question has been answered, I will
submit the patch.
What I would suggest is to add it to xlformula.cxx, but leave out lotform.cxx
(for now).
Kohei
Thank you.
I
Hi,
Attached patch adds function DATEDIF to calc as defined in ODF1.2 (6.10.3)
WinfriedFrom 61d133beff3ce513dbeb0df82453f3b9a780518b Mon Sep 17 00:00:00 2001
From: Winfried Donkers o...@dci-electronics.nl
Date: Wed, 9 May 2012 16:47:13 +0200
Subject: [PATCH] fdo#44456 added calc function DATEDIF
Hi Eike,
This took a little longer than I expected as I had to figure out what Excel
actually does in DATEDIF. Please see
https://bugs.freedesktop.org/show_bug.cgi?id=44456
for changes I did and test case document. For the final algorithm of the
function itself best take a look at the
Hi Eike,
Heh, sorry for having taken away the work from you :-)
I'll keep that in mind for next time.
:)
I thought I'd get that algorithm solved because I quite know the date
calculation area and the quirks that may be lurking there.
Your quite right, of course.
Usually for spreadsheet
Hi Regina,
Van: Regina Henschel [rb.hensc...@t-online.de]
Verzonden: dinsdag 15 mei 2012 19:55
The page
http://wiki.services.openoffice.org/wiki/Calc/ODFF_Implementation/Examine_functions
lists some missing functions in the lower part. And perhaps you add
yourself to DATEDIF with comment
Also, coukld this page be a source for me to add more formulas that are in
ODF1.2 and not yet in calc?
Yes, it should be pretty up-to-date. Just give us a heads-up what you would
like to pick so we can get into details. If possible we should focus on
functions
defined in the
Just give us a heads-up what you
would like to pick so we can get into details. If possible we should
focus on functions defined in the Small/Medium/Large sets of ODFF in
that order, see
http://docs.oasis-open.org/office/v1.2/cs01/OpenDocument-v1.2-cs01-
From the Small Group, all but AVERAGIF are available.
It is (an other functions) in
http://hg.services.openoffice.org/cws/calcishmakkica/. But that CWS has not
been integrated to Apache OpenOffice yet.
If you will use it for LibreOffice, you should ask Apache to get it under
APL2.0
Should have replied to all...
I had a similar (or even identical) message.
re-make from clean did not help.
What did help was this:
source ooenv
(I used ./ooenv previously, but ooenv can no longer be executed).
I hope this helps :)
Winfried
-Oorspronkelijk bericht-
If a file, like ooenv, is intended to be sourced, that means that the
commands in it are to be executed by the very shell that is sourcing it, as
the
point with them is to affect the environment of that shell.
Running it as a command, i.e. a separate process, which is what ./ooenv
would
Hi Olivier,
I had to manually modify the label dimension to keep the rightmost label on
the right column, and I wonder if I have to do it for all the labels, or I am
hitting a bug there. I must note that the page dimensions are not writen into
the label dimensions, if that matters.
I only
Hello Olivier,
Thank you for looking at. I went further into isolating the issue and opened
https://bugs.freedesktop.org/show_bug.cgi?id=53673
to add samples that shows the problem.
I picked up the bug and put my findings so far in it.
Winfried
Hi all,
Libreoffice 3.6 introduced bug 53673, a problem when working with documents
generated by the label wizard. The layout of the frames gets broken when saving
(or opening?) these documents.
It is possible that the cause of this is in the label wizard (e.g. incorrect
placement of frames),
Dear Michael,
My previous request on the list did not get any response and you seem to
remenber my label-work.
Olivier Hallot reported bug 53673 regarding the label wizard and asked me to
look at it.
I did, but I need some help in solving the problem.
The label wizard code has not been changed
Attached is a fix for bug 53673.
Possibly the deeper cause of the bug is in Writer document save-functions,
therefor I do not intend to close the bug after this fax has been pushed.
The fix is a simplification of the code and produces documents with frames that
represent the labels in a better
Attached patch modifies the calc functions WEEKNUM and WEEKNUM_ADD to
respectively ISOWEEKNUM and WEEKNUM. These latter functions comply with ODFF1.2
The link to the help files has been broken, i.e. WEEKNUM now points to the
(partially out of date) help text for WEEKNUM_ADD, but ISOWEEKNUM does
Hi Caolán,
https://bugs.freedesktop.org/show_bug.cgi?id=53673
Cedric seems to have had a look and the bug is closed. Presumably it's taken
care of now.
Michael Meeks closed the bug as my patch removed the symptoms and suggested to
open a separate bug for remaining issues (comment 44).
Some nitpicking: isEmpty() seems to be accidentally replaced with
getLength().
I noticed this too, it probably crossed a patch from someone else.
@Winfried: Thanks a lot for the patch. Its really cool (at least for me
:) ). In the meanwhile, it would be really great if you could pick more
such
Hello all,
I'm working on bug 44516 and try to address bug 35104 and 41755 simultaneously.
That is, I want to solve the last two first.
The problem is that when using a label form with e.g. 3 labels of 70mm on an A4
sheet (210mm wide), the document is not created correctly (the labels do not
Sorry, title should be where can I find bug 24446
Hello all,
I'm working on bug 44516 and try to address bug 35104 and 41755 simultaneously.
That is, I want to solve the last two first.
The problem is that when using a label form with e.g. 3 labels of 70mm on an A4
sheet (210mm wide), the
The in-file-history of the file that was present in the initial checking shows
Rev 1.62 21 Feb 1997 09:28:52 MA
#36621# neue Umrandungstechnik beruecksichtigen
i.e. that suggests that this code dates back to 1996 or earlier.
Ok, that is clear, not much else to go on than the comment in the
Could this patch be pushed to versions 3.4(.6) and 3.5(.1) as well?
Winfried
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
BTW - can you please add a screenshot + short description of your nice
work to:
Being unfamiliar with this, do you want me to mail text and screenshots to
someone, or is there a way for me to enter/submit the text and screenshots to
the ReleaseNotes/3.6 itself?
Winfried
Stefan Knorr (Astron) wrote
So, do you think there's a chance you could implement the same behaviour for
* Background Colour in Writer
* Font Colour in Calc?
I should expect the behaviour for background color in Writer to be there
already (that is, font background colour) as I use the same
Stefan Knorr (Astron) wrote (3 februari 2012 21:24)
Writer has two background colour functions, ... The
highlighter is already a split button, but Background Colour is not.
By the way, I've actually just discovered even more buttons that would
be eligible for the split-button treatment...
* In
1 - 100 of 839 matches
Mail list logo
