OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Applications => Topic started by: Joop on August 22, 2014, 12:36:02 am

Title: Apache OpenOffice 4.1.1 RC3
Post by: Joop on August 22, 2014, 12:36:02 am
Downloaded the file, its going slow, it took about 12 minutes to complete.  The file name Apache_OpenOffice_4.1.1_os2gcci_install-arc_en-US-rc3-strip.zip suggest some kind of installation program. Didn't found one. There was a readme, but I couldn't discover any words about OS/2 or eComStation nor what you need in order to run the program. Its like something is missing, but I might be wrong.
So, said that, how do I start this monster?

Regards,
Joop 
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: ivan on August 22, 2014, 01:28:48 am
Unzip it, you should find an openoffice 4 directory in there - that is the one you need.

Copy that directory somewhere convenient - we renamed it to openoffice-41 for convenience.

Make a program object with the following:  Path and File Name - <drive>\openoffice-41\program\soffice.exe
                                                               Working Directory - <drive>\openoffice-41\program

                                                              Name the program object to something like OpenOffice 4.1.1

That is it, other than making sure you have all the necessary DLLs available in the DPATH.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Sigurd Fastenrath on August 22, 2014, 08:32:15 am
Good news!

Just donated the money, downloaded the file and will give it a try.

That gives hope for the future of the other OS/2 development started by Lewis, bitwise etc.  :)
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Pete on August 22, 2014, 12:30:04 pm
Hi ivan

Surely DLL files should be available in the LIBPATH not the DPATH ?


regards

Pete
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Andi B. on August 22, 2014, 01:09:23 pm
I start soffice.exe from cmd line in the \program directory. Or by clicking on the symbol in that folder or dragging a reference somewhere ...

No need to play with libpath.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: ivan on August 22, 2014, 01:37:52 pm
Hi Pete,

Yes, you are correct.  My post was made in the early hours of the morning after a 18 hour day at work.

Andi B, unless you have moved the required external DLLs in with the OO DLLs your method will not work - not strictly true if you have the other DLLs in os2\dll which should be in the LIBPATH.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Andi B. on August 22, 2014, 04:25:14 pm
Ivan
Quote
unless you have moved the required external DLLs in with the OO DLLs your method will not work
I do not really understand what you mean with this. AOO dlls are all in \program dir. If you drop a reference somewhere maybe it will be required to set the 'Start in directory' (?) setting in the object. Have to check.

Other required dlls (gcc... libc...) are up to date in \usr\lib by 'yum update' on my system which is of course in libpath.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: ivan on August 22, 2014, 04:44:15 pm
Quote
Other required dlls (gcc... libc...) are up to date in \usr\lib by 'yum update' on my system which is of course in libpath.

Those are the ones I was talking about and not everyone uses RPM/YUM or even has it on their computer.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Matt Walsh on August 22, 2014, 06:44:22 pm
OK, I installed the "https://www.dropbox.com/sh/350r8h2dpuxsg8w/AACiO6nvExrjsIVGBvqaeKqAa/aoo/Apache_OpenOffice_4.1.1_os2gcci_install-arc_en-US-rc3-strip.zip" file.  Unzipped it into OpenOffice 4 directory and tried to run the soffice.exe after updating my yum.  Get error message "failing module:stdcpp6" which I think is a missing dll update.  Any suggestions what I need and where to get it?
Thanks
Matt Walsh
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Silvan Scherrer on August 22, 2014, 07:18:09 pm
Matt

yum install libstdc++6 libsupc++6

regards
Silvan
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Silvan Scherrer on August 22, 2014, 07:22:40 pm
Hi all,

if someone would write a small readme or howto install,  would be more than happy.

regards
Silvan
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Andy Willis on August 22, 2014, 09:31:54 pm
I cheated... I renamed the directories under the Openoffice.org.3 folder (except program where I created a backup folder and moved the stuff to it as ooodoc.dll was in use) and put the stuff from Openoffice4 under it.  That left in place the program objects from the OpenOffice3 install and left the ooodoc.dll which does the associations in place as well.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Joop on August 23, 2014, 01:01:58 am
I have more than one office program which runs in OS/2-eCS. I can start them all if I want to.

I have this command file;

@echo off
set LIBPATH=i:\office\OpenOffice4\program;%LIBPATH%
set path=i:\office\OpenOffice4
I:
cd i:\office\OpenOffice4\program
soffice.exe

I get an error which I can't translate into a missing file or so.

A popup appears with the message
return code: 2
failing module:ICUUC42

That's it, end excution and I'm back on the prompt, did start the commandfile in an eCS command session. I played with some set libpath and set path settings, same popup.

I think that a little readme or reados2 or something won't do harm.

Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: ivan on August 23, 2014, 02:39:08 am
Joop, do you have the extra required DLLs somewhere in your LIBPATH?

Here we have the older beta and now this one running on 9 different machines, all without problems.  A tenth machine has a problem but we expected that because of what it is setup to do.

All of the instances we have running are started from a Program Object with the properties as I listed them near the start of this thread.  We also have both the full version and the stripped down versions starting and working without problems so far - as I type this I have the stripped down version open at a manual I am editing as well and can change between browser and OO without problems.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Joop on August 23, 2014, 03:08:17 am
Joop, do you have the extra required DLLs somewhere in your LIBPATH?
Required what? There is no file with any information for OS/2-eCS with info what you need for a machine, memory or installed libs. So I don't know, but everything else is running fine on my machine, except a few Java programs.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Lewis Rosenthal on August 23, 2014, 05:33:17 am
Hi, guys...

First, Bitwise deserves a big round of applause for the great work in getting this beast up to this level. Truly wonderful work...

Next, a couple tips for those still having difficulty getting started:

There is (apparently) currently no OS/2-specific readme. This is a release candidate, not a finished product. As such, running it for testing purposes is not for the faint of heart!  ;)

If you find that starting soffice.exe or swriter.exe from a prompt in the program directory does not get you anything, try setting:

Code: [Select]
BEGINLIBPATH=.;
to ensure that you aren't possibly trying to load a dll from your (most likely still installed) OOo 3.x installation.

If you find that starting soffice.exe or swriter.exe from a prompt in the program directory yields you an error message, look closely at the failing module in the error dialog. Grab PMDll (from http://home.earthlink.net/~steve53/os2tools/index.html or my FTP mirror ftp://ftp.2rosenthals.com/pub/warpcave/os2tools), unzip it, and load the failing module in that to see what dependency (likely) failed. (In my case this evening, I didn't have libxslt installed - which surprised me, actually - and this caused a cascade failure starting with sal3.dll, which is one of the modules shipped with OOo, and in turn, caused deploy.dll not to load, stopping soffice.exe right after the splash panel came up.)

PMDll is your friend, particularly when you don't have the sources handy to determine exactly what the dependencies actually are. You can load exe's and dll's with it, and it presents a handy tree view. Set the option to test load, and you can make sure that the versions you are loading are the ones which satisfy the required dependencies.

Anyway, HTH, and happy testing (and don't forget to switch to the debug build in case things really do go wrong, so you can get enough information for a useful trouble ticket).

Cheers
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Pete on August 23, 2014, 06:02:26 am
Hi Joop

As I have simply unzipped and OO411rc3 works fine - so far - I can only guess that the requirements are about the same as for an earlier beta of OO4 so here is the readme included with that release:-


------------------------------------------------------------------------------------



Apache OpenOffice 4.0 Developer Build
=====================================


Apache OpenOffice is comprised of six personal productivity applications: a
word processor (and its web-authoring component), spreadsheet, presentation
graphics, drawing, equation editor, and database.

IMPORTANT: These builds are intended to be used for early testing by other
community volunteers. They have no release quality and should not be installed
in a production environment. Developer snapshots can be unstable and are
expected to have bugs.


Installation notes:
-------------------
The package is provided only in zip file format, and it will not use your
OpenOffice GA user configuration.


System requirements:
--------------------
- eComStation 1.x, 2.x
- OS/2 Warp
- 32bit tcpip stack
- the following packages must be installed (dll only)
   libc 0.6.5
   gcc 4.4.6
   gcc 4.4.4
   ssl
   curl
   jpeg
   xslt
   libicu
   z
   xml2
   stdcpp
   mmap
   pthread
   urpo


These files can be installed with the following command:

   yum install libc gcc-4.4.4 gcc-4.4.6 openssl curl libjpeg libxslt libicu zlib libxml2 stdcpp mmap pthread urpo gcc-stdc++-shared-library

if you have a valid rpm/yum installation.
Otherwise you can grab the corresponding zip files from

   http://rpm.netlabs.org/release/00/zip/

Only the dlls are needed.


-----------------------------------------------------------------------------------


Hope the above is of some help - looks like you may need libicu judging by the error message but I think you should also check you have all other need lib files.


Regards

Pete
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: dbanet on August 23, 2014, 10:18:01 am
I have more than one office program which runs in OS/2-eCS. I can start them all if I want to.

I have this command file;

@echo off
set LIBPATH=i:\office\OpenOffice4\program;%LIBPATH%
set path=i:\office\OpenOffice4
I:
cd i:\office\OpenOffice4\program
soffice.exe

I get an error which I can't translate into a missing file or so.

A popup appears with the message
return code: 2
failing module:ICUUC42

That's it, end excution and I'm back on the prompt, did start the commandfile in an eCS command session. I played with some set libpath and set path settings, same popup.

I think that a little readme or reados2 or something won't do harm.

Joop, setting a LIBPATH environment variable doesn't give you anything at all.
If you read your CONFIG.SYS file, you may notice, that in contrast with the environment variable PATH, which is set up with a string like this:
Code: [Select]
SET PATH=C:\OS2; ... ; ... ; ..., LIBPATH is not an environment variable. It is an OS/2 command, that may be executed only during startup (when CONFIG.SYS gets executed):
Code: [Select]
LIBPATH=C:\OS2\DLL;.;C:\usr\lib; ... ; ... ; ..., so setting a LIBPATH environment variable in your local cmd interpreter environment although doesn't fail, but neither does give you anything useful. It does not extend your LIBPATH.

But it is still possible by using BEGINLIBPATH and ENDLIBPATH. These are the features of ours OS/2 command interpreter that allows you to make it (the command interpreter) to extend its own LIBPATH (locally) prepending (BEGINLIBPATH) or appending (ENDLIBPATH) new paths to it. When you then start a child process, like a new OS/2 session, or a program (OpenOffice), it inherits the extended LIBPATH.

So for your case you should've written:
Code: [Select]
SET BEGINLIBPATH=I:\office\OpenOffice4
That would work, although neither BEGINLIBPATH, nor ENDLIBPATH are not environment variables, they are just a way to tell CMD.EXE to extend its LIBPATH.

Although now I can't see how can your script help. In CONFIG.SYS, the global setup of LIBPATH may contain or not contain a dot, i. e. the current working directory. But it is usually there. If you have reasons, you may remove it, but you will usually need to do more work (like writing this script) to start most of the apps. But again, if your global LIBPATH contains the current working directory, creating a program object is just enough.

You can also extend LIBPATH using BEGINLIBPATH (or ENDLIBPATH) with a dot like Lewis said, but I've read somewhere (can't google it back), that the needed command is not straight-forward SET BEGINLIBPATH=., but:
Code: [Select]
SET BEGINLIBPATH=.\.I can't remember the reasons, but I use .\., and it works for me, so I recommend using this instead.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Lewis Rosenthal on August 23, 2014, 04:03:01 pm
Good morning...

Failing ICUUC42:
Code: [Select]
[j:\] yum whatprovides icuuc42.dll
[...]
libicu-4.2.1-1.oc00.i386 : International Components for Unicode (development
                         : files)
Repo        : netlabs-exp
Matched from:
Other       : icuuc42.dll(B



libicu-4.2.1-1.oc00.i386 : International Components for Unicode (development
                         : files)
Repo        : netlabs-rel
Matched from:
Other       : icuuc42.dll(B

[j:\] yum info libicu
[...]
Available Packages
Name       : libicu
Arch       : i386
Version    : 4.2.1
Release    : 1.oc00
Size       : 7.2 M
Repo       : netlabs-exp
Summary    : International Components for Unicode (development files)
URL        : http://ibm.com/software/globalization/icu
License    : IBM Public License
Description: ICU is a set of C and C++ libraries that provides robust and
           : full-featured Unicode support. This package contains the runtime
           : libraries for ICU. It does not contain any of the data files needed

           : at runtime and present in the `icu' and `icu-locales` packages.
           :
           :
           :
           : Authors:
           : --------
           :     The ICU project, International Business Machines (IBM) and
           :     Others.  <icu@oss.software.ibm.com>

Per the earlier mention, install libicu, and the module should not fail.

Also:

Code: [Select]
return code: 2

means:

Code: [Select]
[j:\] help SYS0002

SYS0002: The system cannot find the file specified.

EXPLANATION: The file named in the command does not exist in the
current directory or search path specified or the file name was
entered incorrectly.

ACTION: Retry the command using the correct file name.

Thus, the module (dll) could not be found in order to be loaded.

HTH
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: David McKenna on August 23, 2014, 05:14:34 pm
 Unfortunately, this version of OpenOffice is nearly unusable on my system. After a fresh boot, I can open up to 2 of the apps, the 3rd will not start (gives errors about dll's - I have all needed dll's installed). Neither will just about any other program start. Even after closing the OpenOffice apps, Firefox will not start until I reboot. Opening and closing OpenOffice apps after a few iterations the WPS gets flakey and eventually crashes. It seems to me that shared memory may be getting used up by this beast and not being released (I have 4GB memory btw). The only way I have found to be able to use it is by only using one app at a time and rebooting after using it. Anybody got any tips on how this could be managed?
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: guzzi on August 23, 2014, 05:31:53 pm

 It seems to me that shared memory may be getting used up by this beast and not being released (I have 4GB memory btw). The only way I have found to be able to use it is by only using one app at a time and rebooting after using it. Anybody got any tips on how this could be managed?

Or just fragmented which will lead to the same problems. I have marked the openoffice dlls to load high with above512, this greatly reduces the use of shared memory. I have only tested a little bit, but sofar it seems to work well.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Andreas Schnellbacher on August 23, 2014, 05:45:38 pm
Code: [Select]
yum install libc gcc-4.4.4 gcc-4.4.6 openssl curl libjpeg libxslt libicu zlib libxml2 stdcpp mmap pthread urpo gcc-stdc++-shared-library
Thanks Pete. After installing/updating some of these packages, the icuuc42 error msg is gone for me.

I had previously installed OOo 3.2. Unfortunately executing swriter.exe with cmd.exe from the 4.1.1rc3 program dir gives no error msg anymore, but two entries in popuplog.os2:

Code: [Select]
------------------------------------------------------------

08-23-2014  17:37:34  SYS3176  PID 0090  TID 0001  Slot 00b7
F:\APPS\OPENOFFICE4.1.1RC3\PROGRAM\SOFFICE.BIN
c000001c
14541fe8
EAX=00000001  EBX=003182a3  ECX=003182a0  EDX=00000000
ESI=003182a0  EDI=002d237c 
DS=0053  DSACC=f0f3  DSLIM=ffffffff 
ES=0053  ESACC=f0f3  ESLIM=ffffffff 
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:14541fe8  CSACC=f0df  CSLIM=ffffffff
SS:ESP=0053:0012fdb8  SSACC=f0f3  SSLIM=ffffffff
EBP=00cea38e  FLG=00010246

CPPU3.DLL 0001:00001fe8

------------------------------------------------------------

08-23-2014  17:37:34  SYS3175  PID 0090  TID 0001  Slot 00b7
F:\APPS\OPENOFFICE4.1.1RC3\PROGRAM\SOFFICE.BIN
c0000005
146ca218
P1=00000002  P2=00000004  P3=XXXXXXXX  P4=XXXXXXXX 
EAX=00000000  EBX=1166f638  ECX=1486ec50  EDX=0012fe3c
ESI=0012fe3c  EDI=00000000 
DS=0053  DSACC=f0f3  DSLIM=ffffffff 
ES=0053  ESACC=f0f3  ESLIM=ffffffff 
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:146ca218  CSACC=f0df  CSLIM=ffffffff
SS:ESP=0053:0012fdd8  SSACC=f0f3  SSLIM=ffffffff
EBP=0012fe00  FLG=00010246

SAL3.DLL 0001:0002a218

Some more details:

Any ideas?
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: David McKenna on August 23, 2014, 05:53:03 pm
@ Andreas: make sure the Quickstart from version 3 is not loaded. That one tripped me up at first.

@guzzi: there is a 'highmem' archive file in the directory I got OpenOffice from. I just downloaded it and it appears to be an updated version of ABOVE512 that you mention. I'll give it a try, thanks.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Andi B. on August 23, 2014, 06:04:31 pm
A few observations with 4.1.1rc3 -

Do not use too long paths.
Code: [Select]
T:\Temp\Apache_OpenOffice_4_os2gcci_install123\Apache_OpenOffice_4.1.1_os2gcci_install-arc_en-US\OpenOffice 4\program\soffice.exedoes not work but

Code: [Select]
T:\Temp\Apache_OpenOffice_4_os2gcci_install12\Apache_OpenOffice_4.1.1_os2gcci_install-arc_en-US\OpenOffice 4\program\soffice.exeworks. Seems there is some 128 char limit. I've created a ticket for that.

Memory -
I had all sort of memory leaks. Lower shared memory and higher shared memory run outs when using the dlls marked as HighMem or not. I could not start soffice.exe and immediately closing it more than 7 times before I had to reboot as there was no shared mem left.

But now after fresh reboot and fresh unzip an not loading dlls high it seems AOO gives all memory back when closing. I've successfully tried more than 12 times now. And Above512 still says
Code: [Select]
pm: 200256 sm: 127168  <---512---> pm: 917504 sm: 780552Starting soffice.exe and closing gives the same values.

I don't know why I had this terrible memory leaks before (about 85MB every start/close). Maybe it's because I loaded dlls high (will try soon) ore more likely cause I started different AOO and OO versions (3.3, 4.0, ) in parallel or one after each other. Maybe one of the 4.0 dlls was still loaded and leads to that problem, currently I don't know.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: dbanet on August 23, 2014, 06:16:45 pm
Above512 still says
Code: [Select]
pm: 200256 sm: 127168  <---512---> pm: 917504 sm: 780552Starting soffice.exe and closing gives the same values.

above512's method of determining amounts of memory (DosQuerySysInfo) does not actually give fairly reasonable results. The best way it seems is to use Theseus4 kernel API or Theseus itself.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Matt Walsh on August 23, 2014, 06:22:07 pm
Thanks to Pete, Boris and Lewis I got all the dlls downloaded with yum and set the beginlibpath with .\.   Tried to start the AOO with X:\openofffice4\program\soffice.exe and got a further down error.
This error message says: exception occured raising singleton "/singletons/com.sun.star.deployment.ExtensionManager":   loading library failed: file :///X:/openoffice4/program/../program/deploy.dll"

I looked and the deploy.dll is in the directory noted.  Any further suggestions?
Again I realize it's a RC and I appreciate the help so far.
Thanks
Matt
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: guzzi on August 23, 2014, 06:41:07 pm

This error message says: exception occured raising singleton "/singletons/com.sun.star.deployment.ExtensionManager":   loading library failed: file :///X:/openoffice4/program/../program/deploy.dll"


I had that one too. Means you have still some dependency missing. In my case it was libxslt.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Andreas Schnellbacher on August 23, 2014, 06:49:07 pm
@ Andreas: make sure the Quickstart from version 3 is not loaded. That one tripped me up at first.
Thanks, I made that sure before by renaming the OpenOffice.org.3 dir when I booted to my service partition.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Lewis Rosenthal on August 23, 2014, 07:16:21 pm
@ guzzi: Re: libxslt - as mentioned before, this one got me, too.  ;)

@ Matt: open deploy.dll in PMDll. set the option to test load dlls from the menu. Trace down the tree, looking for red entries. As guzzi and I discovered, this one was a missing libxslt package. Another good way to be sure that you don't have a conflicting dll in memory is to set LIBPATHSTRICT=T (just in case there is some stray copy of something from somewhere else which is getting in the way).

All: FWIW, I grabbed Yuri's highmem utility from dropbox, and (blindly) marked all OO dll's in \program to load code and data high (-b option) via:
Code: [Select]
for %a in (*.dll) do highmem -b %a

(highmem does not accept wildcards).

I was impressed with the amount of shared memory it left me when I had Writer, Calc, and Impress loaded (with documents: 4-sheet worksheet, 27-page odt, and a 20+ slide odp). However, upon closing the last of them, my system trapped (000e).  :P

It will take me a bit of experimenting to determine just which ones should get loaded high (likely the biggest ones, though the little ones tend to fragment more when unloading, for obvious reasons), but the opportunity is there, at least.

Overall, I'm still impressed not only by the build, but by OO4, in general. It generates pdfs considerably faster than 3.2, and the pdfs are tighter (I trimmed almost 1K off of a 17K pdf, so thinking about some really big documents, this looks like it is considerably more efficient). I haven't tested printing, yet, nor have I really worked any of the apps, for that matter (I'd like to get them to exit cleanly; even before marking the dll's, I was seeing an exceptq report upon exit).

Cheers, and good luck, guys. Hopefully, you'll be able to get past these dependency issues (and whatever else) quickly, and without much more frustration.

Cheers
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: dbanet on August 23, 2014, 07:24:59 pm
Code: [Select]
for %a in (*.dll) do highmem -b %a

(highmem does not accept wildcards).

Hrm? For me it does.

However, upon closing the last of them, my system trapped (000e).

Do you use the latest kernel (14.106_SMP)?
The bug with trapping on unload of DLLs loaded high has been fixed in 106.

It will take me a bit of experimenting to determine just which ones should get loaded high (likely the biggest ones, though the little ones tend to fragment more when unloading, for obvious reasons), but the opportunity is there, at least.

When the first build of AOO4 came up, I've got it running well with DLLs loaded high as well, and I simply did highmem *.dll in all directories where I found any DLLs (it's not the `program' one only).

By the way, I also run with all Qt4 DLLs loaded high (the webkit one is pretty huge, heh), with no apparent problem.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Lewis Rosenthal on August 23, 2014, 07:52:19 pm
Code: [Select]
for %a in (*.dll) do highmem -b %a

(highmem does not accept wildcards).

Hrm? For me it does.

That's odd, isn't it. Perhaps I didn't try a wildcard with the parameter, and only highmem * to get a report of status. I'll try again when the time presents itself. Thanks for letting me know.

However, upon closing the last of them, my system trapped (000e).

Do you use the latest kernel (14.106_SMP)?
The bug with trapping on unload of DLLs loaded high has been fixed in 106.

Ah, no. I've been moving between kernels quite a bit recently, and am currently using 14.105_W (this is a ThinkPad T43 with a 2.26GHz Dothan, single core). I planned on swapping in the 14.106_W kernel soon, so it looks like a good time.

It will take me a bit of experimenting to determine just which ones should get loaded high (likely the biggest ones, though the little ones tend to fragment more when unloading, for obvious reasons), but the opportunity is there, at least.

When the first build of AOO4 came up, I've got it running well with DLLs loaded high as well, and I simply did highmem *.dll in all directories where I found any DLLs (it's not the `program' one only).

By the way, I also run with all Qt4 DLLs loaded high (the webkit one is pretty huge, heh), with no apparent problem.

Good to know, Boris; thanks. I'll do some more experimenting, but I've certainly gotten a lot farther along than I did with 4.0.

Cheers
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: David McKenna on August 23, 2014, 08:06:51 pm
 Using the HIGHMEM utility on my OpenOffice \program directory made a HUGE difference. I used 'highmem -b *.dll' from the command line and so far all apps always start, I have not had any traps (using Kernel 14.106) nor have I been able to get the WPS to crash anymore.  So good I went to try it on SeaMonkey, but SeaMonkey wouldn't start afterwards, so I undid the highmem setting and re-tried with 'highmem -c *.dll'. That worked great (not sure why the difference). I need to study this little gem some more....
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Joop on August 23, 2014, 08:18:24 pm
I used 'highmem -b *.dll' , 'highmem -c *.dll'. That worked great (not sure why the difference).
Hi David,
usage: HIGHMEM [-options] {DLL module file} ...
Without options, current DLL object information are dumped.
Options:
 --quiet   -q  quiets (no message)
 --verbose -v  verbose output (-v -v even more verbose)
 --code    -c  marks pure 32bit code objects as 'loading above 512MB'
 --data    -d  marks pure 32bit data objects as so
 --both    -b  marks both of pure 32bit code and data objects
 --unmark  -u  unmarks 'loading above 512MB' pure 32bit code/data objects
 --exclude -x file  list of files to be excluded (max 1024 entries
 --help    -?  show this help

Got it form highmem-20140406-os2.zip.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: David McKenna on August 23, 2014, 08:47:42 pm
Joop,

  Yes... I saw that and that is why I tried the -c switch. But why does -b work on OpenOffice but not SeaMonkey? SeaMonkey DLL's have both code and data segments according to highmem -v...

  I have also now loaded all the XCenter plugin DLL's high... even more free shared memory!
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: dbanet on August 23, 2014, 09:21:18 pm
Joop,

  Yes... I saw that and that is why I tried the -c switch. But why does -b work on OpenOffice but not SeaMonkey? SeaMonkey DLL's have both code and data segments according to highmem -v...

  I have also now loaded all the XCenter plugin DLL's high... even more free shared memory!

Actually very close to all of existing application DLLs may be loaded high. This option should be considered stable and used extensively.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: guzzi on August 23, 2014, 10:15:50 pm
Joop,

  Yes... I saw that and that is why I tried the -c switch. But why does -b work on OpenOffice but not SeaMonkey? SeaMonkey DLL's have both code and data segments according to highmem -v...


Don't know about seamonkey, but in FF24 only xul.dll will fail with data segments loaded high. According to the testing I've done loading data segments high does not yield much extra free shared low memory.

I also have odin and java load high. (except user32.dll and WINMM.dll, which will give problems with java when loaded high). It would be nice if developers would have rpm/yum package with modules already marked high)
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: David McKenna on August 23, 2014, 11:04:23 pm

Actually very close to all of existing application DLLs may be loaded high. This option should be considered stable and used extensively.

  Yes... I am beginning to understand that. It brings up a new question: when should 'shared memory' be used and when 'high memory'? What are the advantages and disadvantages? Is 'shared memory' for shared code? If so, it would seem like QT, Java and Odin would be better off staying in shared memory. If they are loaded high, are they not shared among different apps? I'm just trying to get my head around how this dual memory concept is supposed to be used....
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: dbanet on August 24, 2014, 02:24:03 am

Actually very close to all of existing application DLLs may be loaded high. This option should be considered stable and used extensively.

  Yes... I am beginning to understand that. It brings up a new question: when should 'shared memory' be used and when 'high memory'? What are the advantages and disadvantages? Is 'shared memory' for shared code? If so, it would seem like QT, Java and Odin would be better off staying in shared memory. If they are loaded high, are they not shared among different apps? I'm just trying to get my head around how this dual memory concept is supposed to be used....

There are (DISCLAIMER: this is how I understand and what I know, I may be highly inaccurate, or even completely wrong! Think on your own!) generally four user memory arenas: low (<512 MiB) private and shared and high (>=512 MiB) private and shared ones. Yes, shared memory is for shared objects like DLLs, which are Qt (it's spelled Qt, not QT) and Odin (partly).

Dividing memory on low and high memory arenas make it possible to seamlessly run 16-bit applications, which is one of the greatest advantages of OS/2 (well, was?).

Low memory is also used for interaction with device drivers, as the current way it is organized limits it to low memory: the main driver code may be 32-bit, but some external parts of it must be 16-bit (it is possible it will get changed within the OS/4 project).

There are possibly some other places where low memory must be used, but that shouldn't be significant, as the amounts of memory used by system components are hardly comparable to the amounts used by modern applications like FFox or AOO.

When you mark a DLL as loadable high, it gets loaded to the high shared arena, which means that it's still shared, as well as that scarce low memory (limited to 512 megs minus amount of allocated low private memory) isn't wasted.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: dbanet on August 24, 2014, 02:27:41 am
Don't know about seamonkey, but in FF24 only xul.dll will fail with data segments loaded high. According to the testing I've done loading data segments high does not yield much extra free shared low memory.

I also have odin and java load high. (except user32.dll and WINMM.dll, which will give problems with java when loaded high). It would be nice if developers would have rpm/yum package with modules already marked high)

It would be cool if you document your experience with loading DLLs into the high memory and the results you get (workability, stability) on the OS/2World Wiki (http://www.os2world.com/wiki/index.php/Main_Page).
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: David McKenna on August 24, 2014, 03:05:12 am
Thanks Boris! You have made it crystal clear...


There are (DISCLAIMER: this is how I understand and what I know, I may be highly inaccurate, or even completely wrong! Think by your own!)

  Well... of course, this should be the 'small print' on the entire Internet.. 8-D
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Dave Yeo on August 24, 2014, 04:41:56 am
So where are people downloading the latest  highmem?
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Lewis Rosenthal on August 24, 2014, 04:56:24 am
So where are people downloading the latest  highmem?

Hey, Dave...

It should be the last item on the list, here:

https://www.dropbox.com/sh/350r8h2dpuxsg8w/AAAjVtD4f5_FaFghfUg_l6BYa/aoo

The source is included. Yuri has included his copyright 2012-2014, and the Apache license, and states that it is based on above512.

Cheers
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Dave Yeo on August 24, 2014, 05:40:42 am
Thanks, that definitely helped SeaMonkey. For others, don't forget components/suite.dll.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Lewis Rosenthal on August 24, 2014, 09:57:41 pm
Code: [Select]
for %a in (*.dll) do highmem -b %a

(highmem does not accept wildcards).

Hrm? For me it does.

Indeed, it does. As I mentioned, the help text is misleading, as:

Code: [Select]
[j:\] highmem *.dll

would appear to list the status of the tested modules, yet only reveals:

Code: [Select]
Processing module : <module>

instead, it is necessary to use the -v switch (or any other switch). Oddly though, my first time around, I got an actual error, so there must be another highmem which was in %PATH% getting picked up, I guess.

However, upon closing the last of them, my system trapped (000e).

Do you use the latest kernel (14.106_SMP)?
The bug with trapping on unload of DLLs loaded high has been fixed in 106.

Well, switching to 14.106_W4 got me the same trap. Changing the flag to only load the code high seems to have resolved it (I think).

Thanks again.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: guzzi on August 25, 2014, 12:10:50 am

It would be cool if you document your experience with loading DLLs into the high memory and the results you get (workability, stability) on the OS/2World Wiki (http://www.os2world.com/wiki/index.php/Main_Page).

I wrote a how-to but have no idea how to add it to the wiki. I am not familiar with HTML. I have it as an odt file. Any volunteers to proof read / edit  / add it to the wiki?
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: dbanet on August 25, 2014, 01:04:46 am

It would be cool if you document your experience with loading DLLs into the high memory and the results you get (workability, stability) on the OS/2World Wiki (http://www.os2world.com/wiki/index.php/Main_Page).

I wrote a how-to but have no idea how to add it to the wiki. I am not familiar with HTML. I have it as an odt file. Any volunteers to proof read / edit  / add it to the wiki?

It's not HTML there, but Wiki markup (http://en.wikipedia.org/wiki/Wiki_markup) instead. Either ways neither Wiki markup nor HTML are not even close to "hard" to use for plain text markup tasks like you have.

I'll consider putting that on Wiki, if I manage to open the file you attached.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: dbanet on August 25, 2014, 01:06:50 am
Well, switching to 14.106_W4 got me the same trap. Changing the flag to only load the code high seems to have resolved it (I think).

Thanks again.

Strange. Seems it's not completely fixed. Maybe it is like that for the *_W4 kernels only? Have you tried 14.106_SMP?
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: guzzi on August 25, 2014, 01:13:10 am

It's not HTML there, but Wiki markup (http://en.wikipedia.org/wiki/Wiki_markup) instead. Either ways neither Wiki markup nor HTML are not even close to "hard" to use for plain text markup tasks like you have.

I'll consider putting that on Wiki, if I manage to open the file you attached.

Thanks. I created the document with OO 4)
It might not be hard to use, but I have never used it yet, so I'd have to learn. At the moment I have little time for that. I did put it on the list)
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Lewis Rosenthal on August 25, 2014, 01:47:53 am
Well, switching to 14.106_W4 got me the same trap. Changing the flag to only load the code high seems to have resolved it (I think).

Thanks again.

Strange. Seems it's not completely fixed. Maybe it is like that for the *_W4 kernels only? Have you tried 14.106_SMP?

I experimented with the 14.106_SMP kernel last week, in an effort to install ACPI (this is a ThinkPad T43, with a 2.26GHz Pentium M 780 Dothan; a single core CPU). ACPI does not like the machine at all (no version has), so I rolled back to the Geyserville daemon for power management and the UNI kernel which I had been using (14.105_UNI). Steven Levine mentioned to me that he thought I might get about 10% better performance from the W4 kernel than the UNI kernel (both of which run significantly cooler without ACPI, and I noticed an overheat condition almost immediately after installing the SMP kernel), so I switched to the 14.105_W4 kernel. He and David Azarewicz both agreed that I should really move to the 106 (no matter which flavor, I think), due to the bug fixes in 106 vs 105. After my earlier experience with the trap exiting OO4, and your mention of this being fixed in 106, Boris, I figured that it was probably a good time.

I should probably get a trap dump of this situation to debug further, but frankly, if loading only the code high works, and the difference between that and loading both code and data high is trivial, I'll likely just stick with what I've got. I just thought it was worth mentioning, here.

Cheers
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: guzzi on August 25, 2014, 03:59:32 am
How do I get the spellchecker to work? I downloaded some dictionaries and installed them (extensions) but I can't get the spellchecker to work,
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Lewis Rosenthal on August 25, 2014, 09:13:17 am
How do I get the spellchecker to work? I downloaded some dictionaries and installed them (extensions) but I can't get the spellchecker to work,

Confirmed; bug opened: https://issues.apache.org/ooo/show_bug.cgi?id=125501

also note Check for updates window which does not show in front of Extension Manager:

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

It is also important to note that dictionaries must be compatible with OO4. I initially tried using my 3.2 dictionaries, and while they installed, I noted the ages of them (I did not subsequently try to check them for updates, but installed English manually).
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: guzzi on August 25, 2014, 12:13:30 pm
How do I get the spellchecker to work? I downloaded some dictionaries and installed them (extensions) but I can't get the spellchecker to work,

Confirmed; bug opened: https://issues.apache.org/ooo/show_bug.cgi?id=125501


Someone marked your bug as a duplicate of another one. I checked, solution there is to delete or rename user profile directory. That did -not- solve the problem for me, so it either isn't a duplicate of that bug or we have an os/2 specific problem.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Martin Iturbide on August 25, 2014, 02:03:00 pm
Thanks for the information.

After the ....
Quote
yum install libc gcc-4.4.4 gcc-4.4.6 openssl curl libjpeg libxslt libicu zlib libxml2 stdcpp mmap pthread urpo gcc-stdc++-shared-library
...OpenOffice started to work fine here.

I still need to try it out, my only complain for the moment are the icons :)
It is great to have this application updated on the platform. Thanks to Bitwise works !!
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Lewis Rosenthal on August 25, 2014, 05:58:51 pm
How do I get the spellchecker to work? I downloaded some dictionaries and installed them (extensions) but I can't get the spellchecker to work,

Confirmed; bug opened: https://issues.apache.org/ooo/show_bug.cgi?id=125501


Someone marked your bug as a duplicate of another one. I checked, solution there is to delete or rename user profile directory. That did -not- solve the problem for me, so it either isn't a duplicate of that bug or we have an os/2 specific problem.

This is definitely not a dupe. I can confirm on two different systems.

Also opened new bugs for incorrect/unexpected location of profile (should respect %HOME%) and crash when creating new profile.

To track bugs for the OS/2 version, follow this link:

https://issues.apache.org/ooo/buglist.cgi?list_id=156388&op_sys=OS/2&query_format=advanced&resolution=---

At this point, the more feedback we can provide, the better it will be for Yuri and the team to get issues resolved and to get to a GA version. We are so close to the mainline releases for this, we shouldn't lose momentum. Also, the better a showing we can get in the bug tracker from as many users as possible (not just opening new bugs, but participating in clarifying existing ones and solving others - some things may be user-related; the OOo docs in general are in need of updating, in many cases, and things have changed considerably between major releases), the better our chances are at being taken seriously and not just as a fringe element, using the app on some obscure platform (this is apparently how we are viewed WRT OpenSSL, where like Mozilla, there is serious consideration being given to dropping support in the main project - we can't afford to have this happen by being silent and hoping for someone else to step up).

Cheers

Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: dbanet on August 25, 2014, 07:46:58 pm
(this is apparently how we are viewed WRT OpenSSL, where like Mozilla, there is serious consideration being given to dropping support in the main project - we can't afford to have this happen by being silent and hoping for someone else to step up).

I agree to your words wholly, but who do you expect to step up to maintain OpenSSL/2?
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Lewis Rosenthal on August 25, 2014, 08:18:28 pm
(this is apparently how we are viewed WRT OpenSSL, where like Mozilla, there is serious consideration being given to dropping support in the main project - we can't afford to have this happen by being silent and hoping for someone else to step up).

I agree to your words wholly, but who do you expect to step up to maintain OpenSSL/2?

OpenSSL builds on OS/2. If all that is required to keep OS/2 in the official project is to push changes upstream, almost anyone could do that, based on Paul Smedley's diffs. While I'd like to find someone else to do it, if nobody does step forward, I will (I need OpenSSL; it is running on my Apache server right now, supporting several SSL sites). I would also consider funding a maintainer to do this. OpenSSL, unlike the absurd "RapidRelease" cycle which Mozilla has adopted (which in ten years' time will bring us things like Firefox 122 - no kidding; do the math!), is normally released in much more manageable intervals.

Anyway, this is a discussion for another thread, I'm afraid! We should stick to OO4, here, though I'm happy to discuss maintaining OSS apps and how we can make that happen.

Cheers
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Silvan Scherrer on August 25, 2014, 08:40:43 pm
(this is apparently how we are viewed WRT OpenSSL, where like Mozilla, there is serious consideration being given to dropping support in the main project - we can't afford to have this happen by being silent and hoping for someone else to step up).

I agree to your words wholly, but who do you expect to step up to maintain OpenSSL/2?

OpenSSL builds on OS/2. If all that is required to keep OS/2 in the official project is to push changes upstream, almost anyone could do that, based on Paul Smedley's diffs. While I'd like to find someone else to do it, if nobody does step forward, I will (I need OpenSSL; it is running on my Apache server right now, supporting several SSL sites). I would also consider funding a maintainer to do this. OpenSSL, unlike the absurd "RapidRelease" cycle which Mozilla has adopted (which in ten years' time will bring us things like Firefox 122 - no kidding; do the math!), is normally released in much more manageable intervals.

Anyway, this is a discussion for another thread, I'm afraid! We should stick to OO4, here, though I'm happy to discuss maintaining OSS apps and how we can make that happen.

Cheers

just to let you all know, we already maintain a svn branche at netlabs svn. We even provide a rpm for it. To put the small changes we did upstream would need not much effort from our side. But as time flies too fast, we just didn't care on that. If the community thinks it would be good to have all upstream we would try to contact them.

regards
Silvan
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Silvan Scherrer on August 25, 2014, 08:41:44 pm
another small note:

at the Apache OpenOffice RC3 download site, we added a small readme explaining what requirements are needed.

regards
Silvan
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Silvan Scherrer on August 28, 2014, 02:46:08 pm
Apache OpenOffice for eCS (OS/2) update

We just uploaded an update to the recently announced Apache OpenOffice 4.1.1 RC3.
This update enables the so called category B modules. The most known module of this category
is most likely the spellchecker. Where solver and scripting are others in this category.

Apache OpenOffice is the free and open productivity suite, consisting of
several mighty applications, such as Calc, Writer, Base, Impress and
several more. Apache OpenOffice is compatible to the leading commercial
productivity suite.

bww bitwise works is commited to provide the latest version available,
which will be version 4.1.1.

Download Apache OpenOffice 4.1.1 RC3 update 1 at:
https://www.dropbox.com/sh/350r8h2dpuxsg8w/AAAjVtD4f5_FaFghfUg_l6BYa/aoo
If you have issues please use the debug file to get more
debug output.

If you like Apache OpenOffice, please pass by our online shop at
http://www.bitwiseworks.com/shop  and buy Apache OpenOffice for
eCS(OS/2). This donations save the ongoing development and bugfixing.

To fill a bug please use:https://issues.apache.org/ooo/

kind regards
Silvan Scherrer
CTO bww bitwise works GmbH

Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: dbanet on August 28, 2014, 08:43:06 pm
just to let you all know, we already maintain a svn branche at netlabs svn. We even provide a rpm for it. To put the small changes we did upstream would need not much effort from our side. But as time flies too fast, we just didn't care on that. If the community thinks it would be good to have all upstream we would try to contact them.

Silvan, it is understandable that it's perfectly possible to maintain an OS/2 fork even if the maintainer doesn't know OS/2 exists.

I understand your point that this whole OpenSSL-drops-OS/2-support drama is taken a bit too seriously, but also, apart of easing later development, the goal is to make some more people treat us seriously, as Lewis said. I think it is kinda important.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Greggory Shaw on September 01, 2014, 12:46:43 am
Where can you get the 14.106_W kernel ?
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Dave Yeo on September 01, 2014, 03:40:01 am
Comes with eCS 2.2b2 (and I believe 2.2b1) and should be located in \os2\install\w4 after install. Some people also seem to have FP#6 where it originates, where they got it I don't know but probably from Mensys.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: dbanet on September 01, 2014, 03:39:44 pm
Where can you get the 14.106_W kernel ?

Greggory, please see your private messages inbox.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Pete on November 11, 2014, 04:40:41 pm
Hi All

I have been using OO4.1.1RC3 with update1 applied for a few weeks and have successfully printed a few documents within that time. However, all those documents have been black text only.

On trying to print a document with text in various colours I find that the printed output is mono with greyscale used to represent colours.

I was using cups148, ghostscript8.71 and gutenprint5.2.7 so updated to the latest cups packages - cups2.0, ghostscript9.15 and gutenprint5.2.10 along with various dll files required - to see if that would help. The answer is No.

The lack of colour output seems to be the print output from OO4 as printing the same document from OO115 works as it should - coloured text is coloured not greyscale.

Is this an OO4 for OS/2 problem or the same for all platforms?

Where should I report this problem?


Regards

Pete

Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: David McKenna on November 11, 2014, 11:33:16 pm
  Pete,

  I noticed the same issue with CUPS (after you mentioned it). I also cannot print any images with AOO4 and CUPS (other apps work). However, I can print everything with AOO4 and the OMNI printer driver. So it seems it may not be strictly AOO at fault, but some interaction with the PSPrint driver and AOO4. In any case, you can report bugs here: https://issues.apache.org/ooo/ . It's a good idea to put 'OS/2' somewhere in the title of the bug.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Pete on November 13, 2014, 12:51:02 am
Hi Dave

I thought I had replied to your post previously but it has not appeared nearly 24 hours later

Sounds like you are saying that printing works fine from AOO4 when using the omni driver but not when using the postscript driver.

Seems to indicate the possibility of something not quite right in the AOO4 postscript printer output...

I guess I could do "Print to file" for the same document from OO115 and AOO4 and compare the output to see if I can spot anything suggestive of a problem with the AOO4 output.

This does not seem to be a cross platform problem so I have opened a bug
      https://issues.apache.org/ooo/show_bug.cgi?id=125850

Hopefully those involved in the OS/2 port will see the bug and investigate.


Regards

Pete
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: David McKenna on November 13, 2014, 01:33:01 pm
Hi Pete,

  Yes, I can print normally from every AOO4 app with the OMNI printer. With CUPS I can only get black and white text, no images or drawings/graphs (yet... still playing around with options).

  I'm certainly no expert on these things, but I was under the impression that when printing, the data from the app to the printer is the same regardless of the driver used and it is the driver that does the translation to the printer language. That is what led me to be more suspicious of the PSPRINT driver. Maybe someone more knowledgeable than I could chime in on this.

  Your idea of print-to-file the same document from both versions and doing a compare sounds good. I'd be very interested in the results...

Regards,

Dave McKenna
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Pete on November 14, 2014, 06:02:40 pm
Hi Dave

If I understand it right the postscript driver is the software interface to the hardware(printer) so the application is responsible for delivering postscript output compatible with the drivers requirements.

Looking at the raw postscript files generated by OO115 and AOO4 from the same document when printed to file I am fairly sure that the printing program affects how the postscript is generated as the files are different sizes and have different contents  - and they are using the same printer driver.

The output from AOO4 has duplicate sections which may or may not affect output.

Interestingly the output from OO115 shows

       %%BeginFeature: *ColorModel Gray
      <</cupsColorSpace 0/cupsColorOrder 0/cupsBitsPerColor 8/cupsPreferredBitsPerColor 16>>setpagedevice
      %%EndFeature


where the output from AOO4 shows

      %%BeginFeature: *ColorModel RGB
      <</cupsColorSpace 1/cupsColorOrder 0/cupsBitsPerColor 8/cupsPreferredBitsPerColor 16>>setpagedevice
      %%EndFeature


As OO115 prints in colour and AOO4 in greyscale I think I expected OO115 to show *ColorModel RGB and AOO4 output to show *ColorModel Gray.

I wonder why the AOO4 output has "/cupsColorSpace 1"... maybe related to the *ColorModel RGB bit...


As an experiment I changed the *ColorModel RGB to *ColorModel Gray and /cupsColorSpace 1 to /cupsColorSpace 0 in the AOO4 output, deleted the duplicate lines, saved the file and attempted to print it using cups:-

[J:\CUPS\BIN]lpr -P RX585 "I:\Users\peter\HOME\My Documents\OO4_EpsonRX585.PS"


No, No Colour Output!   :-(


Not knowing much about postscript I doubt if I can "debug" the AOO4 output to find and correct any error(s). I see AOO4.1.1 for OS/2 is just about to go GA so I will see if this problem has already been fixed before investigating further.


Regards

Pete




Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: mickhead on November 26, 2014, 12:35:16 am
Greetings,
This RC third functioning well as far on installation. My system show no signals of shared memory problems as of yet. Good work, developers.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Pete on November 26, 2014, 03:16:19 pm
Hi Mick Head

Do you have a postscript printer? - if "No"  do you use the cups printing system?

If you have a postscript printer or use cups try to print a document containing coloured text from Writer. Do you get colour printing or are colours converted to greyscale?


Regards

Pete

Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Alex Taylor on November 27, 2014, 07:18:23 am
Pete,
What happens if you actually view the 'printed' output PS file? e.g. in GSView.  Does it show up in colour or mono? That should be a pretty reliable indicator of whether the problem is in CUPS or in one of the earlier stages.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Pete on November 27, 2014, 07:14:23 pm
Hi Alex

Yes, tried that already: I used "Print to file" and then tried viewing the print file in GSView5.0

The text is displayed in black and greyscale - exactly like the printed output.

I'm convinced that the problem is the AOO4.1.1 print output as the same document prints in colour from OO115 for Windows running via ar5os2.exe,  OO3.1.1 for OS/2 and OO3.2.0 for OS/2.


Regards

Pete

Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Silvan Scherrer on November 28, 2014, 12:01:12 pm
I'm convinced that the problem is the AOO4.1.1 print output as the same document prints in colour from OO115 for Windows running via ar5os2.exe,  OO3.1.1 for OS/2 and OO3.2.0 for OS/2.

Hi
could you also add the output of OO 3.2 to the ticket? As comparing 3.2 to 4.1 does a lot better than comparing to 1.1.5.

regards
Silvan
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Silvan Scherrer on November 28, 2014, 06:06:33 pm
Hi Alex

Yes, tried that already: I used "Print to file" and then tried viewing the print file in GSView5.0

The text is displayed in black and greyscale - exactly like the printed output.

I'm convinced that the problem is the AOO4.1.1 print output as the same document prints in colour from OO115 for Windows running via ar5os2.exe,  OO3.1.1 for OS/2 and OO3.2.0 for OS/2.


Regards

Pete
Hi,

please try the following: in jop properties from the printer change "Color" to "Black and white". And report if this fixes printing.
When this is the case we know thats what we found out is the same as you saw.
Please also update the aoo ticket according to your findings.

thanks and regards
Silvan
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Pete on November 29, 2014, 02:24:46 am
Hi Silvan

Just read the post from Yuri on the bug report page https://issues.apache.org/ooo/show_bug.cgi?id=125850

I can confirm that setting the printer driver properties, effects page, to Grayscale instead of RGB Color produces colour output.

For whatever reason I am currently unable to login to the bug report - login refused due to invalid username/password; I changed the password and got the same result - so am currently unable to confirm Yuris comment.


Regards

Pete
 
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Jan-Erik Lärka on December 02, 2014, 09:05:55 am
Where do I change macro security level in Apache OpenOffice 4.1.1?
I know it's not possible "inside" OpenOffice", but should be possible in some configuration file or registry.

In 3.2 it was possible to add some xml code to *common.xcd". I wrote a rexx script that did (and does) it nicely, though only in 3.2 as it seem to have changed in 4.x?
I need to export multiple Charts as png images (every Friday night) with code I've written.

//Jan-Erik
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Jan-Erik Lärka on December 02, 2014, 12:46:06 pm
Where do I change macro security level in Apache OpenOffice 4.1.1?
...
//Jan-Erik

Never mind, found it in another file :-)
I'll rewrite my script.
//Jan-Erik
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Pete on December 05, 2014, 02:01:58 am
Hi All

I was wrong - the problem with no colour output when printing from Writer is an ecups.drv/psprint.drv problem.

Alex Taylor has released an updated psprint.drv which seems to fix this problem - only had very limited testing here but it has worked fine so far. I guess Alex would appreciate as many people as possible testing it  http://www.altsan.org/os2/printing/psprint-test-141203.zip


Regards

Pete
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Alex Taylor on December 05, 2014, 12:27:50 pm
Hi All

I was wrong - the problem with no colour output when printing from Writer is an ecups.drv/psprint.drv problem.

Alex Taylor has released an updated psprint.drv which seems to fix this problem - only had very limited testing here but it has worked fine so far. I guess Alex would appreciate as many people as possible testing it  http://www.altsan.org/os2/printing/psprint-test-141203.zip


Regards

Pete

Yes, indeed. Please note that, this being a quick test build, I didn't observe any proper release niceties like updating the README file or even the BLDLEVEL version (it still reports 30.904 but with a build date of 2014 Dec 3).
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: guzzi on December 05, 2014, 04:26:45 pm
Hi All

I was wrong - the problem with no colour output when printing from Writer is an ecups.drv/psprint.drv problem.

Alex Taylor has released an updated psprint.drv which seems to fix this problem - only had very limited testing here but it has worked fine so far. I guess Alex would appreciate as many people as possible testing it  http://www.altsan.org/os2/printing/psprint-test-141203.zip


Regards

Pete

Yes, indeed. Please note that, this being a quick test build, I didn't observe any proper release niceties like updating the README file or even the BLDLEVEL version (it still reports 30.904 but with a build date of 2014 Dec 3).

It works for me. I have not been able to print colour from any program with the ecups driver since a reinstall of cups about a year ago. With psprint.drv I can print in colour again).
Thanks, Alex!
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: David McKenna on December 06, 2014, 04:21:52 pm
 Thanks, Alex!.... it works here too.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Jan-Erik Lärka on December 10, 2014, 04:17:42 pm
My main basic macro update all tabs, data pilotes and add conditional formatting as expected.
The other Basic macro can't export the charts as png-images (but on other platforms).
What should I do?

Regards,
//Jan-Erik



Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Dave Yeo on December 11, 2014, 05:56:37 am
Possibly you need libpng (and its dependency zlib) installed.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Jan-Erik Lärka on December 11, 2014, 12:49:55 pm
Possibly you need libpng (and its dependency zlib) installed.

Wohoo!
yum install libpng  :D
Thank you Dave!

Noticed one small thing on a printout however.
Spreadsheet, page 2,  printout with header show ¤%&/()=#=../¤ (Odd characters), page 1 ok.

Your OpenOffice 4.1.1 is stable and fast.

//Jan-Erik Lärka
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Alex Taylor on January 22, 2015, 03:36:57 am
I've updated PSPRINT again and I'd like to release it generally.  I'd appreciate some testing first.
http://www.altsan.org/os2/printing/psprint-30_905.zip

This is pretty close to the previous build but I've added a new checkbox to job properties which allows forcing greyscale for printers using ColorModel (it won't appear for other types of printer).  This should not really be necessary unless you're printing to file, but Pete reported not getting greyscale output at all with the last build.  Maybe an odd CUPS issue.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Doug Bissett on January 23, 2015, 07:01:50 pm
Quote
I've updated PSPRINT again and I'd like to release it generally.  I'd appreciate some testing first.
http://www.altsan.org/os2/printing/psprint-30_905.zip (http://www.altsan.org/os2/printing/psprint-30_905.zip)

I decided to try this. It seems to work in some cases, although something goes wrong if I select Greyscale in AOO4 (I haven't trird to analyze that, yet). More importantly, If I try to start Lotus Approach, Approach crashes. I have a process dump, that shows this:
Code: [Select]
                        TRAP SCREEN INFORMATION


------------------------------------------------------------
Trap screen 1 found at address #70:989c
This screen is most likely related to a previous trap.

P1=XXXXXXXX  P2=XXXXXXXX  P3=XXXXXXXX  P4=XXXXXXXX   
CS:EIP=ffef:0000e411  CSACC=00df  CSLIM=0000ffff
SS:ESP=1da7:03b4efb4  SSACC=****  SSLIM=********
EBP=03b20fe8  FLG=00010282
EAX=00000000  EBX=0000efc0  ECX=00000007  EDX=00000020
ESI=03b20ff4  EDI=299a0000   
DS=0053  DSACC=d0f3  DSLIM=5fffffff   
ES=0053  ESACC=d0f3  ESLIM=5fffffff   
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=*******
 
No Symbols Found
#

------------------------------------------------------------
Trap screen 2 found at address #70:9c84

EAX=00000000  EBX=0000efc0  ECX=00000007  EDX=00000020
ESI=03b20ff4  EDI=299a0000   
DS=0053  DSACC=d0f3  DSLIM=5fffffff   
ES=0053  ESACC=d0f3  ESLIM=5fffffff   
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=ffef:0000e411  CSACC=00df  CSLIM=0000ffff
SS:ESP=1da7:03b4efb4  SSACC=****  SSLIM=********
EBP=03b20fe8  FLG=0001028

ASCII found at #70:9c84-12 is 00000000 (Exception Code?)
00000000:  Unknown error code in 3175 trap info:

ASCII found at #70:9c84-9 is 00000000. (Linear Address?)

ASCII found after trap screen: (Module name Object:Offset?)
PSPRINT.DRV 0001:0001a993
 
No Symbols Found

 
#

I am using CUPS 1.4.8, because I still can't get CUPS 2.0.0 to work.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Pete on January 24, 2015, 02:47:47 am
Hi Alex

On testing psprint-30_905 I found RGB Color setting prints in Color, Greyscale setting prints in Color, Pre-convert to greyscale prints Greyscale.

Looks like psprint-30_905 resolves the problem here.


Regards

Pete
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Alex Taylor on January 24, 2015, 11:38:27 am
Thanks, Pete.

Doug, did you have PSPRINT installed before (and not get this crash)?  If so, what build? And are you using any printer objects with it that use imported PPD files?

Crashes of this nature often indicate something wrong with an imported PPD driver.
Title: Re: Apache OpenOffice 4.1.1 RC3
Post by: Doug Bissett on January 24, 2015, 08:53:22 pm
Quote
Doug, did you have PSPRINT installed before (and not get this crash)?  If so, what build? And are you using any printer objects with it that use imported PPD files?

I had psprint-30_904.zip installed, but I don't think I ever opened Lotus Approach when it was installed (only a few days). Before that I had the default (hpecups, I think) from CUPS 1.4.8, and it was fine.

I have no idea if it uses an imported PPD file. I know that I didn't do it, so I suspect not.

I seem to recall having similar problems, with Lotus programs, when playing with printer drivers, years ago, but I don't remember the details.