A question about StarBasic
Hi~ I'm totally green at StarBasic and VBA. Now I have a question about CreateObject. I installed SAP and have below macros. Dim SapGuiAuto As Variant Set SapGuiAuto = CreateObject(SAPGUI) But I got error BASIC runtime error. '91' Module cannot be loaded; invalid format when executing CreateObject(SAPGUI) Then I debugged code then found all SbxFactory instances creation failed. I found below SbxFactory instances but don't know clearly what are they. SbiFactory, seems it's for create pure StarBasic objects SbTypeFactory, seems it's for create user defined objects SbClassFactory, seems it's for create user defined classes SbOLEFactory, seems it's for create OLE objects SbFormFactory, is it for create form controls? SbUnoFactory, seems it's for create UNO structs In my scenario, which instance should work? Is that SbTypeFactory or SbClassFactory? But why they don't work? Is that because StarBasic only support some predefined objects? Or I lost something? How can I enable the support for SAP objects? Could anybody teach me? Thanks Clarence
Re: [RELEASE]: new snapshot build for AOO 4.0.1
On 8/30/13 6:17 PM, Larry Gusaas wrote: I clicked on the link to download the en-GB language pack. It downloaded the full version instead. It seems the other language packs would do the same. On 2013-08-30 7:27 AM Jürgen Schmidt wrote: we have prepared a new snapshot build for AOO 4.0.1 for Windows, MacOS and Linux based on the SNAPSHOT tag. The SNAPSHOT tag rev. 1518670 is based on revision 1518667 on branch AOO401 ups, seems to be a copy/replace issue, now it works Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: new snapshot build for AOO 4.0.1
On 8/31/13 11:13 PM, Mr. Phan Anh wrote: Can you apply the Vietnamese to this snapshot? it will be included in the next one. I see that the UI is 100% compete now perfect. Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
4.0.1_release_blocker granted: [Bug 123111] Vietnamese (vi) translation update for OpenOffice 4.0.1
j...@apache.org has granted Andrea Pescetti pesce...@apache.org's request for 4.0.1_release_blocker: Bug 123111: Vietnamese (vi) translation update for OpenOffice 4.0.1 https://issues.apache.org/ooo/show_bug.cgi?id=123111 --- Additional Comments from j...@apache.org approve showstopper request - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
review granted: [Bug 122840] Ranged names don't work anymore : [Attachment 81430] Fix patch
Oliver-Rainer Wittmann o...@apache.org has granted Clarence GUO clarence.guo...@gmail.com's request for review: Bug 122840: Ranged names don't work anymore https://issues.apache.org/ooo/show_bug.cgi?id=122840 Attachment 81430: Fix patch https://issues.apache.org/ooo/attachment.cgi?id=81430action=edit --- Additional Comments from Oliver-Rainer Wittmann o...@apache.org patch looks good. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: 4.0.1 release and distribution.
On 9/1/13 4:45 PM, janI wrote: On 1 September 2013 15:31, Rob Weir robw...@apache.org wrote: On Sun, Sep 1, 2013 at 5:42 AM, janI j...@apache.org wrote: On 1 September 2013 11:27, janI j...@apache.org wrote: Hi. I had a talk on #asfinfra today, regarding our upcomming 4.0.1 release. Sync on mirrors takes about a week, and the mirror can in general not hold 4.0 and 4.0.1 Is this a change? The current published advice is that the mirrors take no more than 24 hours to sync: https://www.apache.org/dev/release-publishing.html#distribution no actually not, the problem is the size of our distribution, with 4.0 it took 8 days and one Chinese mirror has not updated fully yet. Therefore the current suggestion is to a) remove 4.0 from mirrors GA - 1week = 12 september b) update 4.0.1 to mirrors GA = 19 september. The downside is that mirrors will have the 4.0 ready for download for upto a week. The problem is we don't know for certain a GA date a week in advance. We can just estimate. But as we saw with 4.0.0, a last minute defect can delay things by a week or more. We have a choice, we can wait until GA (as we did last time, where it took several weeks after GA before downloads were in place), or take a chance. I opt for the chance, I think it is important to have the mirrors in place when we announce our release. I think most of the downloads are going over SourceForge so having the mirrors a little bit later in sync shouldn't be a big problem. I would prefer one simple to follow approach. And the synch is done in a way that is suitable for the mirrors. A further question how do we count the downloads from the ASF mirrors or can we count them at all? So in practice this means that there could be more than a week where 4.0.0 is not on the mirrors. Maybe this is not a problem? I hope not, we loose some downloads, but hopefully the users will try again. The two things to watch out for (and you have probably already considered these, but I'll mention them just in case): 1) We should not remove the 4.0.0 hashes and signature files from /dist. These are referenced even when the binaries are downloaded from SourceForge. @henkp: can you make sure of that, please 2) We need to make sure SourceForge is not rsyncing from /dist and mirror the 4.0.0 removal. I assume that will be the case. And I assume 4.0.1 goes to archive then? If I remember right, we (andrea) have to move it to the archive (I presume you mean 4.0). no, it goes automatically to archive as far as I know Juergen rgds jan I. -Rob An alternative suggestion, is to rename 4.0 to 4.0.x on the mirrors and have a 4.0 symlink pointing at 4.0.x. That way, we simply replace the 4.0.x file, after GA, and mirrors do not have a time without a package. I personally like the rename idea, so can we do lazy consensus on that ? I have updated issue 6654, and Henkp is copied on this mail. rgds jan I Second try, sorry for the first mail. I had a talk on #asfinfra today, regarding our upcomming 4.0.1 release. Sync on mirrors takes about a week, and the mirror can in general not hold 4.0 and 4.0.1 Therefore the current suggestion is to a) remove 4.0 from mirrors GA - 1week = 12 september b) update 4.0.1 to mirrors GA = 19 september. The downside is that mirrors will have the 4.0 ready for download for upto a week (SF will be faster). For 4.1 we should consider an alternative way. Use 4.1.x on the mirrors and have a 4.1 symlink pointing at 4.1.x. That way, we simply replace the 4.1.x file, after GA, and mirrors do not have a time without a package. That's an interesting approach that could work. -Rob I have updated issue 6654, and Henkp is copied on this mail. rgds jan I - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: 4.0.1 release and distribution.
On 2 September 2013 09:26, Jürgen Schmidt jogischm...@gmail.com wrote: On 9/1/13 4:45 PM, janI wrote: On 1 September 2013 15:31, Rob Weir robw...@apache.org wrote: On Sun, Sep 1, 2013 at 5:42 AM, janI j...@apache.org wrote: On 1 September 2013 11:27, janI j...@apache.org wrote: Hi. I had a talk on #asfinfra today, regarding our upcomming 4.0.1 release. Sync on mirrors takes about a week, and the mirror can in general not hold 4.0 and 4.0.1 Is this a change? The current published advice is that the mirrors take no more than 24 hours to sync: https://www.apache.org/dev/release-publishing.html#distribution no actually not, the problem is the size of our distribution, with 4.0 it took 8 days and one Chinese mirror has not updated fully yet. Therefore the current suggestion is to a) remove 4.0 from mirrors GA - 1week = 12 september b) update 4.0.1 to mirrors GA = 19 september. The downside is that mirrors will have the 4.0 ready for download for upto a week. The problem is we don't know for certain a GA date a week in advance. We can just estimate. But as we saw with 4.0.0, a last minute defect can delay things by a week or more. We have a choice, we can wait until GA (as we did last time, where it took several weeks after GA before downloads were in place), or take a chance. I opt for the chance, I think it is important to have the mirrors in place when we announce our release. I think most of the downloads are going over SourceForge so having the mirrors a little bit later in sync shouldn't be a big problem. I would prefer one simple to follow approach. And the synch is done in a way that is suitable for the mirrors. I think that rules out links, because of the problem of maintaing parity between artifacts and sigs/hashses. A further question how do we count the downloads from the ASF mirrors or can we count them at all? http://www.apache.org/dev/release.html#downloads So in practice this means that there could be more than a week where 4.0.0 is not on the mirrors. Maybe this is not a problem? I hope not, we loose some downloads, but hopefully the users will try again. The two things to watch out for (and you have probably already considered these, but I'll mention them just in case): 1) We should not remove the 4.0.0 hashes and signature files from /dist. These are referenced even when the binaries are downloaded from SourceForge. @henkp: can you make sure of that, please 2) We need to make sure SourceForge is not rsyncing from /dist and mirror the 4.0.0 removal. I assume that will be the case. And I assume 4.0.1 goes to archive then? If I remember right, we (andrea) have to move it to the archive (I presume you mean 4.0). no, it goes automatically to archive as far as I know http://www.apache.org/dev/release.html#how-to-archive and http://www.apache.org/dev/release.html#when-to-archive [For projects with smaller footprints the old and new releases should normally overlap whilst the mirrors catch up.] Juergen rgds jan I. -Rob An alternative suggestion, is to rename 4.0 to 4.0.x on the mirrors and have a 4.0 symlink pointing at 4.0.x. That way, we simply replace the 4.0.x file, after GA, and mirrors do not have a time without a package. I personally like the rename idea, so can we do lazy consensus on that ? I have updated issue 6654, and Henkp is copied on this mail. rgds jan I Second try, sorry for the first mail. I had a talk on #asfinfra today, regarding our upcomming 4.0.1 release. Sync on mirrors takes about a week, and the mirror can in general not hold 4.0 and 4.0.1 Therefore the current suggestion is to a) remove 4.0 from mirrors GA - 1week = 12 september b) update 4.0.1 to mirrors GA = 19 september. The downside is that mirrors will have the 4.0 ready for download for upto a week (SF will be faster). For 4.1 we should consider an alternative way. Use 4.1.x on the mirrors and have a 4.1 symlink pointing at 4.1.x. That way, we simply replace the 4.1.x file, after GA, and mirrors do not have a time without a package. That's an interesting approach that could work. -Rob I have updated issue 6654, and Henkp is copied on this mail. rgds jan I - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A question about StarBasic
Hi Clarence, Am 02.09.2013 08:47, schrieb Clarence GUO: Hi~ I'm totally green at StarBasic and VBA. Now I have a question about CreateObject. I installed SAP and have below macros. Dim SapGuiAuto As Variant Set SapGuiAuto = CreateObject(SAPGUI) SAPGUI must be an ActiveXObject. Does Set SapGuiAuto = CreateObject(Excel.Sheet) work? Regards Peter - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: new snapshot build for AOO 4.0.1
On 9/2/13 9:50 AM, Jürgen Schmidt wrote: On 8/30/13 6:17 PM, Larry Gusaas wrote: I clicked on the link to download the en-GB language pack. It downloaded the full version instead. It seems the other language packs would do the same. On 2013-08-30 7:27 AM Jürgen Schmidt wrote: we have prepared a new snapshot build for AOO 4.0.1 for Windows, MacOS and Linux based on the SNAPSHOT tag. The SNAPSHOT tag rev. 1518670 is based on revision 1518667 on branch AOO401 ups, seems to be a copy/replace issue, now it works ok, Linux lang packs are not available, I have overseen this. I have also a problem with editing the wiki page. I get an error: A version of this page you were editing at Sep 02, 2013 07:48 was not saved. Do you want to view the change, resume editing or discard it? If I click discard or resume editing I get a message that the page does not exist. Means I can't change it anymore and Herbert got the message that page is currently edit by me and can't make changes as well. Does anybody know how to solve this problem? Clearing browser cache and cookies doesn't help Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
4.0.1_release_blocker granted: [Bug 122982] Copying spreadsheet into another document in bit map format has disappeared in Version 4. Worked on Version 3.
j...@apache.org has granted Armin Le Grand armin.le.gr...@me.com's request for 4.0.1_release_blocker: Bug 122982: Copying spreadsheet into another document in bit map format has disappeared in Version 4. Worked on Version 3. https://issues.apache.org/ooo/show_bug.cgi?id=122982 --- Additional Comments from j...@apache.org approve showstopper request - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] smaller footprint on dist.
On 2 September 2013 09:33, Jürgen Schmidt jogischm...@gmail.com wrote: On 9/2/13 12:55 AM, sebb wrote: On 1 September 2013 23:48, janI j...@apache.org wrote: Hi. I am considering how we can have a smaller footprint on dist and mirrors. One of the ideas is to have a pure exe, pure language oxt and pure dictionaries on the physical disk, and the have a more intelligent download page. Would it be possible (and preferable) to make a download page, where the user. a) selected version (exe) b) selected (multiple) languages (language pack without dictionary) c) selected (mutiple) dictionaries. The choices should be combined into a filename == exe+lang(s)+dict(s). Which is sent to the server as a download request. On the server we would have a backend script that packed the items together just like postprocess/instsetoo does today, so the user would get 1 file. I know how to make the backend script, but the UI could be a problem ? I think it is no new idea and the first question is how we handle the signatures? WIth the current build, the combined packages are created upfront and signed by the RM. Provided that the packages are put together in the same way from the same component parts, the sigs will still be valid. So the RM would still need to create the combined packages, but each could be junked after creating the sig. However one might want to keep them in a separate area for SourceForge which does seem to be able to handle the volume. Or indeed use the concatenation approach if that can be combined witrh rsync (or whatever SF uses to fetch the stuff). Obviously hashes can be created the same way. If a separate download / installer is used, the problem does not arise as the parts/sigs don't change. There's another issue with concatenation by the server: if this requires server configuration, then mirrors will have to do it as well. That may be a step too far. It would be technically possible to use a different strategy for the ASF mirrors as opposed to SF downloads. E.g. SF continues as now, ASF mirrors use two downloads or download/installer. Since the vast bulk of downloads are likely to be from SF, would that be practical? I just posted to a different thread much the same thoughts. Another way to solve UI issue might be to generate a (small) downloader in each language + OS combination and have that do the download. Though I've just realised that would not allow a download manager to be used for the main download(s). Again no new ideas and work for such a special downloader/instaler was already ongoing in former times but never made it in the public repo. We should take some important points into account. One click installation for end users is very important. Offline distribution is also important for users with low bandwidth. Juergen rgds jan I. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A question about StarBasic
Thanks Peter, Yes Set SapGuiAuto = CreateObject(Excel.Sheet) works. Why SAPGUI must be an ActiveXObject? Is it by design? Clarence 2013/9/2 Peter Eberlein pet@refofd.verwalt-berlin.de Hi Clarence, Am 02.09.2013 08:47, schrieb Clarence GUO: Hi~ I'm totally green at StarBasic and VBA. Now I have a question about CreateObject. I installed SAP and have below macros. Dim SapGuiAuto As Variant Set SapGuiAuto = CreateObject(SAPGUI) SAPGUI must be an ActiveXObject. Does Set SapGuiAuto = CreateObject(Excel.Sheet) work? Regards Peter --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] smaller footprint on dist.
On 9/2/13 11:06 AM, sebb wrote: On 2 September 2013 09:33, Jürgen Schmidt jogischm...@gmail.com wrote: On 9/2/13 12:55 AM, sebb wrote: On 1 September 2013 23:48, janI j...@apache.org wrote: Hi. I am considering how we can have a smaller footprint on dist and mirrors. One of the ideas is to have a pure exe, pure language oxt and pure dictionaries on the physical disk, and the have a more intelligent download page. Would it be possible (and preferable) to make a download page, where the user. a) selected version (exe) b) selected (multiple) languages (language pack without dictionary) c) selected (mutiple) dictionaries. The choices should be combined into a filename == exe+lang(s)+dict(s). Which is sent to the server as a download request. On the server we would have a backend script that packed the items together just like postprocess/instsetoo does today, so the user would get 1 file. I know how to make the backend script, but the UI could be a problem ? I think it is no new idea and the first question is how we handle the signatures? WIth the current build, the combined packages are created upfront and signed by the RM. Provided that the packages are put together in the same way from the same component parts, the sigs will still be valid. So the RM would still need to create the combined packages, but each could be junked after creating the sig. However one might want to keep them in a separate area for SourceForge which does seem to be able to handle the volume. Or indeed use the concatenation approach if that can be combined witrh rsync (or whatever SF uses to fetch the stuff). Obviously hashes can be created the same way. If a separate download / installer is used, the problem does not arise as the parts/sigs don't change. There's another issue with concatenation by the server: if this requires server configuration, then mirrors will have to do it as well. That may be a step too far. It would be technically possible to use a different strategy for the ASF mirrors as opposed to SF downloads. E.g. SF continues as now, ASF mirrors use two downloads or download/installer. Since the vast bulk of downloads are likely to be from SF, would that be practical? I just posted to a different thread much the same thoughts. Another way to solve UI issue might be to generate a (small) downloader in each language + OS combination and have that do the download. Though I've just realised that would not allow a download manager to be used for the main download(s). Again no new ideas and work for such a special downloader/instaler was already ongoing in former times but never made it in the public repo. We should take some important points into account. One click installation for end users is very important. Offline distribution is also important for users with low bandwidth. If we want to go in this direction we should think about a new installer that can handle updates as well. But we should keep app stores of modern operating systems in mind as well. I still would love to see AOO in the Apple App Store in the future and the Windows App Store. Juergen Juergen rgds jan I. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A question about StarBasic
On 9/2/13 11:09 AM, Clarence GUO wrote: Thanks Peter, Yes Set SapGuiAuto = CreateObject(Excel.Sheet) works. Why SAPGUI must be an ActiveXObject? Is it by design? whatever it is in detail it is not part of AOO by default and probably comes from somewhere else. Juergen Clarence 2013/9/2 Peter Eberlein pet@refofd.verwalt-berlin.de Hi Clarence, Am 02.09.2013 08:47, schrieb Clarence GUO: Hi~ I'm totally green at StarBasic and VBA. Now I have a question about CreateObject. I installed SAP and have below macros. Dim SapGuiAuto As Variant Set SapGuiAuto = CreateObject(SAPGUI) SAPGUI must be an ActiveXObject. Does Set SapGuiAuto = CreateObject(Excel.Sheet) work? Regards Peter --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [announce] genLang extract is ready.
On 9/1/13 4:03 PM, Rob Weir wrote: On Sat, Aug 31, 2013 at 1:07 PM, janI j...@apache.org wrote: Hi I am pleased to inform you, that I have reached a major milestone with genLang. genLang is now integrated in the build system (for extraction), and I have carefully tested that genLang extract (generation of .pot template files) is 100% identical to the existing system (except for the approx 5 errors in the old system). Sources are in branches/l10n40 (based on trunk approx start august) R1519182. The work flow is: 1) run build --all --genPO or build --genPO 2) on pootle server: cd aooGenLang; svn up pootle update_stores (with parms as normal) 3) on translate.a.o update against templates 4) translate 5) on pootle server: pootle sync_stores (with parms as normal) cd aooGenLang; svn commit Now translated files are available in our source tree. I have tested all these steps. We can make a number of elegant optimizations, a) allow committers to commit directly in pootle (removes 5) b) allow committers to run svn up (req. a simple php page and removes 2,3) If someone could review the branch, it would be real nice. Also I need to check build on windows/mac. In the meantime I will integrate genLang convert so we can get all current translations into the new system. and finally integrate genLang merge that generates sources with languages. Nice! This is going to be a great simplification compared to what we had before. It should help us scale up to support many more languages. Thanks for the sustained effort on this! indeed a huge step forward, perfect. Based on my experience in the past the problems with mismatched tags in the help files (that can break the build) I would not commit the changes from Pootle directly. I don't know how we can address this in a good way. Maybe do a weekly update and solve all potential problems. I will build it on MacOS... Juergen -Rob rgds jan I. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: propose snapshot build for AOO 4.0.1
On 9/1/13 9:53 AM, Fernando Cassia wrote: On Fri, Aug 23, 2013 at 12:58 AM, Jürgen Schmidt jogischm...@gmail.com wrote: http://people.apache.org/~jsc/developer-snapshots/snapshot/ The wiki is not yet updated and I won't have time to do it. Thanks! What is the difference between Windows and Windows2 subdir contents? no difference, I started copy to windows2 and running out of time. I deleted the old snapshots and linked windows to windows2 Sorry for the confusion Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Building comphelper
On 28.08.2013 23:37, Steele, Raymond wrote: While build AOO 4.0, the build fails in module comphelper. It seems to be complaining about the boost/integer_fwd file. /usr/local/include/boost/integer_fwd.hpp line 137, Error: Illegal value for template parameter. /usr/local/include/boost/integer_fwd.hpp line 137, Error: Cannot use class specialization with non-classes. integer_fwd.cpp contains the following on line 136 and 137: 136: template 137:struct low_bits_mask_t ::std::numeric_limitsunsigned char::digits; Any ideas? Has anyone run into this before. https://issues.apache.org/jira/browse/STDCXX-937 might have to do with this. It mentions a compiler bug 6703971 but that doesn't seem to be available any more. I suggest to update the compiler to its latest patch level. Of course it would also interesting to know what type ::std::numeric_limitsunsigned char::digits on that platform. The error message looks as if this was not an integer but a class. The C++ spec requires that the type should be an int. Please check the limits include file. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Bundling dictionaries with langpacks
On 8/31/13 12:27 PM, Andrea Pescetti wrote: Users have reported that the Italian language pack does not contain the Italian dictionary. If I recall correctly, technically we have had the possibility to bundle dictionaries with langpacks since OpenOffice 3.x (anyway, 3.3 or earlier). good question, first we have to figure out if it is possible at all today to bundle dictionaries with language packs. Juergen Do we have support for it in the current extensions.lst mechanism? For example, it would make sense to specify that: - The Italian full version should contain the English and Italian dictionaries - The Italian langpack should contain the Italian dictionary Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Building comphelper
On 28.08.2013 23:54, Steele, Raymond wrote: I'm not sure why I am having so many issues with comphelper, but I am also getting the following: /opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/rtl/math.hxx, line 315: Error: The function isfinite must have a prototype /opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/rtl/math.hxx, line 328: Error: The function isfinite must have a prototype /opt/aoo-4.0.0/main/solver/400/unxsoli4.pro/inc/rtl/math.hxx, line 339: Error: The function isfinite must have a prototype Each instance of the above is complaining about the use of SAL_MATH_FINITE. which I think is defined in mathconf.h Yes, I suggest to experiment with the different SAL_MATH_FINITE definitions. According to the C99 standard it should be isfinite() and according to the C++ standard it should be std::isfinite() in cmath. Before C99 this was more platform dependent, e.g. it may have been called finite() or _finite(). On newer gcc's also __builtin_isfinite() is available. Hope that helps, Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Building comphelper
On 28.08.2013 23:37, Steele, Raymond wrote: While build AOO 4.0, the build fails in module comphelper. It seems to be complaining about the boost/integer_fwd file. /usr/local/include/boost/integer_fwd.hpp line 137, Error: Illegal value for template parameter. /usr/local/include/boost/integer_fwd.hpp line 137, Error: Cannot use class specialization with non-classes. integer_fwd.cpp contains the following on line 136 and 137: 136: template 137:struct low_bits_mask_t ::std::numeric_limitsunsigned char::digits; Any ideas? Has anyone run into this before. https://issues.apache.org/jira/browse/STDCXX-937 might have to do with this. It mentions a compiler bug 6703971 but that doesn't seem to be available any more. I suggest to update the compiler to its latest patch level. Of course it would also interesting to know what type ::std::numeric_limitsunsigned char::digits on that platform. The error message looks as if this was not an integer but a class. The C++ spec requires that the type should be an int. Please check the limits include file. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Yet another flyer
On 9/1/13 2:58 AM, Drew Jensen wrote: Yes - that is exactly what it is, an update to that flyer. Ok - Thanks much to Everyone - particularly for the reminder not to be too loose with trademarks - it prompted me to re-work the short flyer and what I ended up with can be fond here: https://docs.google.com/file/d/0Bx7ZNEXlmR0IQjZiZnFkS2dnUnM (odd, that PDF picked up some verdana fonts when I added the frames..hmm ;-/) Kay mentioned Why AOO items - that is the section I was looking for most guidance on. So, I'll look at Don's suggestions and Kay's tomorrow - BTW the odt file for todays pdf is at: https://docs.google.com/file/d/0Bx7ZNEXlmR0IaW1XcURJa20xQU0 I'll, hopefully, be on-line again Tuesday nice and it reminds me that we should pick up the work on the application icons in time for AOO 4.1 ... Juergen On Sat, Aug 31, 2013 at 12:57 PM, Kay Schenk kay.sch...@gmail.com wrote: On Fri, Aug 30, 2013 at 10:46 AM, Drew Jensen drewjensen.in...@gmail.com wrote: Howdy, I needed to get my head back into thinking AOO look and feel, so decided why not work on a flyer or two - likely this is superfluous to what you already have however https://docs.google.com/file/d/0Bx7ZNEXlmR0IT3JTSWZZSktzODQ The ODT file is at https://docs.google.com/file/d/0Bx7ZNEXlmR0INHdmVUc4cXR0Q1k I believe that flyer is pretty much finished, but any checks/suggestions would be appreciated. For an A3 layout (sorry US Enlgish, so folks will want to change the spelling to, you know - the wrong spelling ;-/ - for other places) https://docs.google.com/file/d/0Bx7ZNEXlmR0IcmRha0tGeFVHc0U and the ODG file is at: https://docs.google.com/file/d/0Bx7ZNEXlmR0IajF0UVRtcHIxczg Some will recognize the second flyer as an update to the original piece that came out with OO.o 2.0. That file is not finished, as you will see and anyone wanting to grab it and edit the information on any part of it - please, please. do, just point me back to an updated version when you are done. Caution - if you want to successfully edit those you will need the MPlus font, available from Sourceforge. This font, last I checked, was only available in English and Japanese.. so a problem for other folks, I know. //drew This looks like a good update to the recent flyer that was done for the 3.4 release and used at FOSDEM-- http://wiki.openoffice.org/wiki/File:AOO_Flyer.pdf The one thing I like from the existing one is the first paragraph from What is Apache OpenOffice. If this could be added this first item and shorten some of your 'Why sections, that would be ideal in my mind. -- - MzK When in doubt, cop an attitude. -- Cat laws - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
4.0.1_release_blocker granted: [Bug 122840] Ranged names don't work anymore
j...@apache.org has granted Oliver-Rainer Wittmann o...@apache.org's request for 4.0.1_release_blocker: Bug 122840: Ranged names don't work anymore https://issues.apache.org/ooo/show_bug.cgi?id=122840 --- Additional Comments from j...@apache.org approve showstopper request - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Possible broken link: from other.html
Thanks for your data. From the values all is fine and the green box should be visible with a link to download the file. Do you have another browser to check if the problem is maybe browser related? Marcus Am 09/01/2013 06:03 PM, schrieb Marcus (OOo): Normally there should a table visible with all possible languages and platforms. If not, it's maybe a problem with the browser. Please try to reload the webpage - also with deleted cache. To see if there is something to improve please give me the output of this webapge (just copypaste the table data): http://www.openoffice.org/download/test/analyze.html Thanks in advance for your help. Marcus Am 09/01/2013 04:54 PM, schrieb Reinhard Richter: Apache OpenOffice Downloads - Official Site - All Builds There is no table with different versions and languages. Cannot download Windows-version zh-cn as required. Coming with a german system and a german Internet Explorer I am offered version de-de only. Need to collect different versions for installation on different PC's in my network. My Internet connection is slow, so I cannot download on each individual PC. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: template troubles in xx pseudo NL website
Am 09/02/2013 08:37 AM, schrieb Andrea Pescetti: Marcus (OOo) wrote: http://ooo-site.staging.apache.org/download/test/index_en.html Only HTML code and JS variable names are used but no other hard-coded strings - at least nothing that has to be translated. http://ooo-site.staging.apache.org/download/test/download_l10n_en.js This file contains the variables with the respective localizeable strings (here: English US). This is very promising, and makes localizing the NL download page much easier. Then those languages that really need to customize structure could still fork the HTML and customize it, but for the majority of languages it will be enough to edit the file with the JS variables. Thanks. The green box is created with JavaScript, so I think I'll put this code also out of the index.html file into the download.js. As there is nothing to change for a NL team, it should be OK. *Important:* Everything related to this topic can now be found in .../test/l10n/: http://ooo-site.staging.apache.org/download/test/l10n/index_en.html Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
4.0.1_release_blocker requested: [Bug 122820] exported image size ignores settings
Armin Le Grand armin.le.gr...@me.com has asked for 4.0.1_release_blocker: Bug 122820: exported image size ignores settings https://issues.apache.org/ooo/show_bug.cgi?id=122820 --- Additional Comments from Armin Le Grand armin.le.gr...@me.com ALG: Tweaked and committed the minimal-invasive version. Requesting the flag for AOO401. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Service Unavailable error when trying to visit wiki.openoffice.org
Seems the problems with the wiki are still on going. Anyone else experiencing a 503 Service Unavailable? On 9/2/13, Alexandro Colorado j...@oooes.org wrote: I got a buch of Service unaviable all through sunday. On 9/2/13, janI j...@apache.org wrote: loads with normal speed here. rgds jan i On Sep 2, 2013 7:24 AM, Tae Wong seotaewon...@gmail.com wrote: This site loads too slow in morning. Visit the wiki using https protocol and SonarQura interface appears. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Alexandro Colorado Apache OpenOffice Contributor http://www.openoffice.org -- Alexandro Colorado Apache OpenOffice Contributor http://www.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Service Unavailable error when trying to visit wiki.openoffice.org
Me, Those day, I can't load the webpage. After pressing F5 a few times, it loaded back to me. But, the lagging of this site fro user Tae Wong and Alexandro Colorado is not wrong, they have discribed it exactly about the lagging situation. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Service Unavailable error when trying to visit wiki.openoffice.org
Hi, On 02.09.2013 15:29, janI wrote: On 2 September 2013 15:20, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Yes, I experienced the same a couple of minutes ago. Now, I am getting server not available I might sit on a better line, I just loaded it without problems, but I have not been on a lot today. It seems wiki is reaching a capacity limit, maybe we have more users than usual. There has been 1 service alert today, thats all. The vm as such is running smoothly. Thanks for having a deeper look. wiki.o.o was back, but only for a short moment. Now, I have again Service Unavailable I will try later again. Best regards, Oliver. On 02.09.2013 15:02, Alexandro Colorado wrote: Seems the problems with the wiki are still on going. Anyone else experiencing a 503 Service Unavailable? On 9/2/13, Alexandro Colorado j...@oooes.org wrote: I got a buch of Service unaviable all through sunday. On 9/2/13, janI j...@apache.org wrote: loads with normal speed here. rgds jan i On Sep 2, 2013 7:24 AM, Tae Wong seotaewon...@gmail.com wrote: This site loads too slow in morning. Visit the wiki using https protocol and SonarQura interface appears. --**--** - To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Alexandro Colorado Apache OpenOffice Contributor http://www.openoffice.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] smaller footprint on dist.
janI wrote: Would it be possible (and preferable) to make a download page, where the user. a) selected version (exe) b) selected (multiple) languages (language pack without dictionary) c) selected (mutiple) dictionaries. The choices should be combined into a filename == exe+lang(s)+dict(s). Which is sent to the server as a download request. On the server we would have a backend script that packed the items together just like postprocess/instsetoo does today, so the user would get 1 file. Obviously this is not for 4.0.1. What I like of this proposal is that the user still downloads one file, which is optimal for the user interface. A beginning could be to simply assemble the same downloads we have now (i.e., the user has no choice: he will get, say, the Italian version with Italian language and dictionary; only, this will be generated rather than pre-built). Then there are a lot of things to consider: 1) Digital signatures: the assembled installer must respect them, and this seems hard to do. 2) Server-side processing: this would likely require some load on the mirrors and some infrastructure standardization. I don't know what's the status on Apache mirrors. 3) Respecting the priorities. Apache is a secondary mirror system, since the Apache mirrors don't have enough space/bandwidth to reliably offer downloads. So whatever is done should not cause technical issues with our primary mirror system (SourceForge), that never had space/bandwidth problems. Note that also the Apache Archives never reported problems so far about the space needed to archive old/current releases. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
4.0.1_release_blocker granted: [Bug 123152] Update bundled Italian (it) dictionary for OpenOffice 4.0.1
j...@apache.org has granted Andrea Pescetti pesce...@apache.org's request for 4.0.1_release_blocker: Bug 123152: Update bundled Italian (it) dictionary for OpenOffice 4.0.1 https://issues.apache.org/ooo/show_bug.cgi?id=123152 --- Additional Comments from j...@apache.org approve showstopper request - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
4.0.1_release_blocker granted: [Bug 123048] line skew parameter is not read from file for connectors in OO draw
j...@apache.org has granted Regina Henschel rb.hensc...@t-online.de's request for 4.0.1_release_blocker: Bug 123048: line skew parameter is not read from file for connectors in OO draw https://issues.apache.org/ooo/show_bug.cgi?id=123048 --- Additional Comments from j...@apache.org approve showstopper request - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
4.0.1_release_blocker granted: [Bug 122820] exported image size ignores settings
j...@apache.org has granted Armin Le Grand armin.le.gr...@me.com's request for 4.0.1_release_blocker: Bug 122820: exported image size ignores settings https://issues.apache.org/ooo/show_bug.cgi?id=122820 --- Additional Comments from j...@apache.org approve showstopper request - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A question about StarBasic
Hallo Peter , Hi Clarence, Am 02.09.2013 08:47, schrieb Clarence GUO: Hi~ I'm totally green at StarBasic and VBA. Now I have a question about CreateObject. I installed SAP and have below macros. Dim SapGuiAuto As Variant Set SapGuiAuto = CreateObject(SAPGUI) SAPGUI must be an ActiveXObject. BTW how do you check if SAPGUI is an ActiveXObject with Windows ? Greetz Fernand Does Set SapGuiAuto = CreateObject(Excel.Sheet) work? Regards Peter - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A question about StarBasic
On Mon, Sep 2, 2013 at 2:47 AM, Clarence GUO clarence.guo...@gmail.comwrote: I'm totally green at StarBasic and VBA I suggest you read this. Since StarOffice was OpenOffice.org -w some addons- which is now AOO, it is totally relevant. http://toolkit.its.isu.edu/Documentation/StarOffice/StarOffice_Basic_Guide_en-US.PDF You will understand then that StarBasic -or OpenOffice Basic- is NOT VBA, and that things aren't a drop-in replacement. Similar, yes. For instance, VBA is Windows-Only and hence can interface to Windows-only services, while StarBasic/OOBasic is, like Open Office,needs to run on multiple platforms. FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto Revolucionario - George Orwell
Re: Service Unavailable error when trying to visit wiki.openoffice.org
On Sep 2, 2013 3:36 PM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 02.09.2013 15:29, janI wrote: On 2 September 2013 15:20, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Yes, I experienced the same a couple of minutes ago. Now, I am getting server not available I might sit on a better line, I just loaded it without problems, but I have not been on a lot today. It seems wiki is reaching a capacity limit, maybe we have more users than usual. There has been 1 service alert today, thats all. The vm as such is running smoothly. Thanks for having a deeper look. wiki.o.o was back, but only for a short moment. Now, I have again Service Unavailable I will try later again. its judt wiki telling to come and haunt me in southern spain :-) rgds jan i ps our vm-admin is still very much up in the air (ref privae) and I am on standby. Best regards, Oliver. On 02.09.2013 15:02, Alexandro Colorado wrote: Seems the problems with the wiki are still on going. Anyone else experiencing a 503 Service Unavailable? On 9/2/13, Alexandro Colorado j...@oooes.org wrote: I got a buch of Service unaviable all through sunday. On 9/2/13, janI j...@apache.org wrote: loads with normal speed here. rgds jan i On Sep 2, 2013 7:24 AM, Tae Wong seotaewon...@gmail.com wrote: This site loads too slow in morning. Visit the wiki using https protocol and SonarQura interface appears. --**--** - To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Alexandro Colorado Apache OpenOffice Contributor http://www.openoffice.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Removing JavaScript from other.html
In the last few weeks we've seen users unable to see the big Download button in http://www.openoffice.org/download/ due to broken (but still used) browsers that failed to parse the JavaScript correctly. And http://www.openoffice.org/download/other.html cannot be used as a fallback due to the same issue. The JavaScript in other.html is used only to generate the page content, and the result is independent of the user's browser: as Marcus explained, it is there for convenience in creating the page. Would it make sense to do the following? 1) Add an All Apache OpenOffice downloads link in the right-hand-side column of http://www.openoffice.org/download/ near the top: this way, we ensure that browsers with poor JavaScript support still display the link. 2) Rename other.html to other_js.html 3) Modify other.html by pasting the actual download table (can be retrieved, for example, with Firebug from other_js.html) in its HTML. This way we add a manual step (step 3) once per release, but we can be sure that virtually all users can download OpenOffice in all cases (working JavaScript, no JavaScript, broken JavaScript). Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Removing JavaScript from other.html
I suggest to checkout some of the many popular fallback libraries for browser compatibility. - modernizr - html5.js - svgweb.js - jquery - bootstrap - http://spoon.net/Browsers/ - https://browserlab.adobe.com/en-us/index.html On Mon, Sep 2, 2013 at 11:08 AM, Andrea Pescetti pesce...@apache.orgwrote: In the last few weeks we've seen users unable to see the big Download button in http://www.openoffice.org/**download/http://www.openoffice.org/download/due to broken (but still used) browsers that failed to parse the JavaScript correctly. And http://www.openoffice.org/**download/other.htmlhttp://www.openoffice.org/download/other.htmlcannot be used as a fallback due to the same issue. The JavaScript in other.html is used only to generate the page content, and the result is independent of the user's browser: as Marcus explained, it is there for convenience in creating the page. Would it make sense to do the following? 1) Add an All Apache OpenOffice downloads link in the right-hand-side column of http://www.openoffice.org/**download/http://www.openoffice.org/download/near the top: this way, we ensure that browsers with poor JavaScript support still display the link. 2) Rename other.html to other_js.html 3) Modify other.html by pasting the actual download table (can be retrieved, for example, with Firebug from other_js.html) in its HTML. This way we add a manual step (step 3) once per release, but we can be sure that virtually all users can download OpenOffice in all cases (working JavaScript, no JavaScript, broken JavaScript). Regards, Andrea. --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Alexandro Colorado Apache OpenOffice Contributor http://www.openoffice.org
Re: Removing JavaScript from other.html
On 9/2/13, Andrea Pescetti pesce...@apache.org wrote: In the last few weeks we've seen users unable to see the big Download button in http://www.openoffice.org/download/ due to broken (but still used) browsers that failed to parse the JavaScript correctly. And http://www.openoffice.org/download/other.html cannot be used as a fallback due to the same issue. The JavaScript in other.html is used only to generate the page content, and the result is independent of the user's browser: as Marcus explained, it is there for convenience in creating the page. How are we using the noscript tag within others? and which kind of content is it trying to plug? Would it make sense to do the following? 1) Add an All Apache OpenOffice downloads link in the right-hand-side column of http://www.openoffice.org/download/ near the top: this way, we ensure that browsers with poor JavaScript support still display the link. Problaby the quicker solution, still is just a patch instead of just doing good webdev. 2) Rename other.html to other_js.html This is a bad idea, I've seen many alternative clones being unmantained by webmasters. 3) Modify other.html by pasting the actual download table (can be retrieved, for example, with Firebug from other_js.html) in its HTML. This way we add a manual step (step 3) once per release, but we can be sure that virtually all users can download OpenOffice in all cases (working JavaScript, no JavaScript, broken JavaScript). Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Alexandro Colorado Apache OpenOffice Contributor http://www.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
slow
Hello, I have a problem because save calc, writer, etc. is very very very slow, there is any problem in openoffice. I tried libreoffice and saved very quickly. My computer is a Intel Centrino Duo, but in the same computer I do openoffice and libreoffice. I prefer Openoffice. Salutacions, *Joan Masgoret i Escolà * Abans d'imprimir aquest correu, penseu en la reducció de consum de paper.
Re: Removing JavaScript from other.html
It also looks a bit 'dumb' that we dont have a link to others from the download page within our no script tag: http://pastebin.mozilla.org/?diff=2959355 We never send people to other if JS is not working, let alone the language table. On Mon, Sep 2, 2013 at 11:49 AM, Alexandro Colorado j...@oooes.org wrote: On 9/2/13, Andrea Pescetti pesce...@apache.org wrote: In the last few weeks we've seen users unable to see the big Download button in http://www.openoffice.org/download/ due to broken (but still used) browsers that failed to parse the JavaScript correctly. And http://www.openoffice.org/download/other.html cannot be used as a fallback due to the same issue. The JavaScript in other.html is used only to generate the page content, and the result is independent of the user's browser: as Marcus explained, it is there for convenience in creating the page. How are we using the noscript tag within others? and which kind of content is it trying to plug? Would it make sense to do the following? 1) Add an All Apache OpenOffice downloads link in the right-hand-side column of http://www.openoffice.org/download/ near the top: this way, we ensure that browsers with poor JavaScript support still display the link. Problaby the quicker solution, still is just a patch instead of just doing good webdev. 2) Rename other.html to other_js.html This is a bad idea, I've seen many alternative clones being unmantained by webmasters. 3) Modify other.html by pasting the actual download table (can be retrieved, for example, with Firebug from other_js.html) in its HTML. This way we add a manual step (step 3) once per release, but we can be sure that virtually all users can download OpenOffice in all cases (working JavaScript, no JavaScript, broken JavaScript). Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Alexandro Colorado Apache OpenOffice Contributor http://www.openoffice.org -- Alexandro Colorado Apache OpenOffice Contributor http://www.openoffice.org
Re: Removing JavaScript from other.html
On Mon, Sep 2, 2013 at 9:08 AM, Andrea Pescetti pesce...@apache.org wrote: In the last few weeks we've seen users unable to see the big Download button in http://www.openoffice.org/**download/http://www.openoffice.org/download/due to broken (but still used) browsers that failed to parse the JavaScript correctly. And http://www.openoffice.org/**download/other.htmlhttp://www.openoffice.org/download/other.htmlcannot be used as a fallback due to the same issue. The JavaScript in other.html is used only to generate the page content, and the result is independent of the user's browser: as Marcus explained, it is there for convenience in creating the page. Would it make sense to do the following? 1) Add an All Apache OpenOffice downloads link in the right-hand-side column of http://www.openoffice.org/**download/http://www.openoffice.org/download/near the top: this way, we ensure that browsers with poor JavaScript support still display the link. 2) Rename other.html to other_js.html 3) Modify other.html by pasting the actual download table (can be retrieved, for example, with Firebug from other_js.html) in its HTML. This way we add a manual step (step 3) once per release, but we can be sure that virtually all users can download OpenOffice in all cases (working JavaScript, no JavaScript, broken JavaScript). Regards, Andrea. I'm not sure it makes sense to provide 2 versions of download/other.html but I understand the JS concern. It might make sense to provide a script, housed in svn, to generate this table -- we had some other cases where this kind of technique was used in the past. It's not as neat as the JS that's being used now, but something to think about. So we would not have a JS generated table at all. --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities. Truth isn't. -- Following the Equator, Mark Twain
Re: Service Unavailable error when trying to visit wiki.openoffice.org
Hi I have filed INFRA-6714, wiki has simply run out of resources. Our popularity is killing us, so what on one hand is positive (many users asking for information) is on the other hand causing problems with the infrastructure. I am in contact with specialists in infra, who have confirmed the problem. I can only hope for a fast solution. I have stepped in, despite the current unclear admin situation, any admins are more than welcome to take over, as I will be offline tomorrow (european time). rgds jan I. On 2 September 2013 17:46, janI j...@apache.org wrote: On Sep 2, 2013 3:36 PM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, On 02.09.2013 15:29, janI wrote: On 2 September 2013 15:20, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Yes, I experienced the same a couple of minutes ago. Now, I am getting server not available I might sit on a better line, I just loaded it without problems, but I have not been on a lot today. It seems wiki is reaching a capacity limit, maybe we have more users than usual. There has been 1 service alert today, thats all. The vm as such is running smoothly. Thanks for having a deeper look. wiki.o.o was back, but only for a short moment. Now, I have again Service Unavailable I will try later again. its judt wiki telling to come and haunt me in southern spain :-) rgds jan i ps our vm-admin is still very much up in the air (ref privae) and I am on standby. Best regards, Oliver. On 02.09.2013 15:02, Alexandro Colorado wrote: Seems the problems with the wiki are still on going. Anyone else experiencing a 503 Service Unavailable? On 9/2/13, Alexandro Colorado j...@oooes.org wrote: I got a buch of Service unaviable all through sunday. On 9/2/13, janI j...@apache.org wrote: loads with normal speed here. rgds jan i On Sep 2, 2013 7:24 AM, Tae Wong seotaewon...@gmail.com wrote: This site loads too slow in morning. Visit the wiki using https protocol and SonarQura interface appears. --**--** - To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Alexandro Colorado Apache OpenOffice Contributor http://www.openoffice.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] smaller footprint on dist.
On 2 September 2013 15:48, Andrea Pescetti pesce...@apache.org wrote: janI wrote: Would it be possible (and preferable) to make a download page, where the user. a) selected version (exe) b) selected (multiple) languages (language pack without dictionary) c) selected (mutiple) dictionaries. The choices should be combined into a filename == exe+lang(s)+dict(s). Which is sent to the server as a download request. On the server we would have a backend script that packed the items together just like postprocess/instsetoo does today, so the user would get 1 file. Obviously this is not for 4.0.1. What I like of this proposal is that the user still downloads one file, which is optimal for the user interface. A beginning could be to simply assemble the same downloads we have now (i.e., the user has no choice: he will get, say, the Italian version with Italian language and dictionary; only, this will be generated rather than pre-built). Then there are a lot of things to consider: 1) Digital signatures: the assembled installer must respect them, and this seems hard to do. As far as I have been able to find out (with the good help of infra colleagues) is: - Only exe have a digital signature meaning this has no impact. But it DO have an impact on checksums, where we need to store all combinations (lots of files, each very small). 2) Server-side processing: this would likely require some load on the mirrors and some infrastructure standardization. I don't know what's the status on Apache mirrors. The server side, processing would happen on our server, and the files would still be located on the mirrors Basically the server side scropt, would split the file request into multiple requests. 3) Respecting the priorities. Apache is a secondary mirror system, since the Apache mirrors don't have enough space/bandwidth to reliably offer downloads. So whatever is done should not cause technical issues with our primary mirror system (SourceForge), that never had space/bandwidth problems. Note that also the Apache Archives never reported problems so far about the space needed to archive old/current releases. The problem is only partial the space itself, much more the size of each release. With a distributed system (like suggested) we can independently release language packs, and the user sees them as integrated in the main AOO release. rgds jan i. Regards, Andrea. --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: slow
On Mon, 2 Sep 2013 18:14:41 +0200 joan masgoret jmasgo...@gmail.com wrote: Hello, I have a problem because save calc, writer, etc. is very very very slow, there is any problem in openoffice. I tried libreoffice and saved very quickly. My computer is a Intel Centrino Duo, but in the same computer I do openoffice and libreoffice. I prefer Openoffice. Salutacions, *Joan Masgoret i Escolà * Abans d'imprimir aquest correu, penseu en la reducció de consum de paper. There are some speed improvemebnts due in AOo 4.0.1 (about end of September) Also, stop Windows indexing OpenOffice files. -- Rory O'Farrell ofarr...@iol.ie - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [announce] genLang extract is ready.
Hi Jan, I have seen, that there is a new project Apache OpenOffice genLang on Pootle and had a look into it for German. 1) I see, that there is a difference in the way file and location is divided compared to the current projects. Is this intended? 2) I see a coding problem for umlauts, for example https://translate.apache.org/de/aooGenLang4/chart2.po/translate/#unit=20600974 The same string is correct in the current Pootle project. Kind regards Regina janI schrieb: Hi I am pleased to inform you, that I have reached a major milestone with genLang. genLang is now integrated in the build system (for extraction), and I have carefully tested that genLang extract (generation of .pot template files) is 100% identical to the existing system (except for the approx 5 errors in the old system). Sources are in branches/l10n40 (based on trunk approx start august) R1519182. The work flow is: 1) run build --all --genPO or build --genPO 2) on pootle server: cd aooGenLang; svn up pootle update_stores (with parms as normal) 3) on translate.a.o update against templates 4) translate 5) on pootle server: pootle sync_stores (with parms as normal) cd aooGenLang; svn commit Now translated files are available in our source tree. I have tested all these steps. We can make a number of elegant optimizations, a) allow committers to commit directly in pootle (removes 5) b) allow committers to run svn up (req. a simple php page and removes 2,3) If someone could review the branch, it would be real nice. Also I need to check build on windows/mac. In the meantime I will integrate genLang convert so we can get all current translations into the new system. and finally integrate genLang merge that generates sources with languages. rgds jan I. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Removing JavaScript from other.html
Am 09/02/2013 06:08 PM, schrieb Andrea Pescetti: In the last few weeks we've seen users unable to see the big Download button in http://www.openoffice.org/download/ due to broken (but still used) browsers that failed to parse the JavaScript correctly. And http://www.openoffice.org/download/other.html cannot be used as a fallback due to the same issue. The JavaScript in other.html is used only to generate the page content, and the result is independent of the user's browser: as Marcus explained, it is there for convenience in creating the page. Would it make sense to do the following? 1) Add an All Apache OpenOffice downloads link in the right-hand-side column of http://www.openoffice.org/download/ near the top: this way, we ensure that browsers with poor JavaScript support still display the link. I don't think so because it would be too unremarkable. Better would be a bigger link with a more prominent location. 2) Rename other.html to other_js.html No, please don't do this. Even when the other.html is just the second choice, it is already very famous from the view point of the Google index: Google search with openoffice other.html -- 1st place with 1,780,00 hits. Google search with other.html -- 2nd place with 1,700,00,00 hits. Better would be an additional other_nojs.html webpage. But then the advantages of the normal other.html but be lapse. ;-) 3) Modify other.html by pasting the actual download table (can be retrieved, for example, with Firebug from other_js.html) in its HTML. Sorry, I don't know what you mean with pasting the table. This way we add a manual step (step 3) once per release, but we can be sure that virtually all users can download OpenOffice in all cases (working JavaScript, no JavaScript, broken JavaScript). The very most users claiming about an invisible table on other.html. But they see the green box on index.html. So, I'm sure it must be a special thing with the table and no general JavaScript problem. However, until today I got no data that shows any hint to this problem. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Removing JavaScript from other.html
Am 09/02/2013 06:51 PM, schrieb Alexandro Colorado: It also looks a bit 'dumb' that we dont have a link to others from the download page within our no script tag: Of course it doesn't make sense to refer to a page with JS when JS is disabled in the broeser. That's why there is no link to the webpage. Marcus On Mon, Sep 2, 2013 at 11:49 AM, Alexandro Coloradoj...@oooes.org wrote: On 9/2/13, Andrea Pescettipesce...@apache.org wrote: In the last few weeks we've seen users unable to see the big Download button in http://www.openoffice.org/download/ due to broken (but still used) browsers that failed to parse the JavaScript correctly. And http://www.openoffice.org/download/other.html cannot be used as a fallback due to the same issue. The JavaScript in other.html is used only to generate the page content, and the result is independent of the user's browser: as Marcus explained, it is there for convenience in creating the page. How are we using thenoscript tag within others? and which kind of content is it trying to plug? Would it make sense to do the following? 1) Add an All Apache OpenOffice downloads link in the right-hand-side column of http://www.openoffice.org/download/ near the top: this way, we ensure that browsers with poor JavaScript support still display the link. Problaby the quicker solution, still is just a patch instead of just doing good webdev. 2) Rename other.html to other_js.html This is a bad idea, I've seen many alternative clones being unmantained by webmasters. 3) Modify other.html by pasting the actual download table (can be retrieved, for example, with Firebug from other_js.html) in its HTML. This way we add a manual step (step 3) once per release, but we can be sure that virtually all users can download OpenOffice in all cases (working JavaScript, no JavaScript, broken JavaScript). Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Removing JavaScript from other.html
Am 09/02/2013 06:49 PM, schrieb Alexandro Colorado: On 9/2/13, Andrea Pescettipesce...@apache.org wrote: In the last few weeks we've seen users unable to see the big Download button in http://www.openoffice.org/download/ due to broken (but still used) browsers that failed to parse the JavaScript correctly. And http://www.openoffice.org/download/other.html cannot be used as a fallback due to the same issue. The JavaScript in other.html is used only to generate the page content, and the result is independent of the user's browser: as Marcus explained, it is there for convenience in creating the page. How are we using thenoscript tag within others? and which kind of content is it trying to plug? Don't ask, just have a look into the webpage. ;-) Would it make sense to do the following? 1) Add an All Apache OpenOffice downloads link in the right-hand-side column of http://www.openoffice.org/download/ near the top: this way, we ensure that browsers with poor JavaScript support still display the link. Problaby the quicker solution, still is just a patch instead of just doing good webdev. 2) Rename other.html to other_js.html This is a bad idea, I've seen many alternative clones being unmantained by webmasters. Just to leave no doubt. If we create new webpages, then we have to maintain them. Marcus 3) Modify other.html by pasting the actual download table (can be retrieved, for example, with Firebug from other_js.html) in its HTML. This way we add a manual step (step 3) once per release, but we can be sure that virtually all users can download OpenOffice in all cases (working JavaScript, no JavaScript, broken JavaScript). Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Removing JavaScript from other.html
Am 09/02/2013 08:08 PM, schrieb Marcus (OOo): Am 09/02/2013 06:08 PM, schrieb Andrea Pescetti: In the last few weeks we've seen users unable to see the big Download button in http://www.openoffice.org/download/ due to broken (but still used) browsers that failed to parse the JavaScript correctly. And http://www.openoffice.org/download/other.html cannot be used as a fallback due to the same issue. The JavaScript in other.html is used only to generate the page content, and the result is independent of the user's browser: as Marcus explained, it is there for convenience in creating the page. Right, at the moment only the following has to be done to change the content of the other.html: - change the version number - change the languages - and if needed its order - change the platforms - and if needed its order That's all. Maybe 5 minutes when typing and committing slow. ;-) No digging into the HTML code, no copy paste and no errors. no detailed tests for broken links which would take 1-2 hours if you do it seriously. That was the main reason for creating the other.html via JS. It's sad to see that it is not working as fine as I thought. Would it make sense to do the following? 1) Add an All Apache OpenOffice downloads link in the right-hand-side column of http://www.openoffice.org/download/ near the top: this way, we ensure that browsers with poor JavaScript support still display the link. I don't think so because it would be too unremarkable. Better would be a bigger link with a more prominent location. 2) Rename other.html to other_js.html No, please don't do this. Even when the other.html is just the second choice, it is already very famous from the view point of the Google index: Google search with openoffice other.html -- 1st place with 1,780,00 hits. Google search with other.html -- 2nd place with 1,700,00,00 hits. Better would be an additional other_nojs.html webpage. But then the advantages of the normal other.html but be lapse. ;-) 3) Modify other.html by pasting the actual download table (can be retrieved, for example, with Firebug from other_js.html) in its HTML. Sorry, I don't know what you mean with pasting the table. This way we add a manual step (step 3) once per release, but we can be sure that virtually all users can download OpenOffice in all cases (working JavaScript, no JavaScript, broken JavaScript). The very most users claiming about an invisible table on other.html. But they see the green box on index.html. So, I'm sure it must be a special thing with the table and no general JavaScript problem. However, until today I got no data that shows any hint to this problem. 4) Use a other_nojs.html webpage (practically the old other.html). Put a link to it into the today's other.html at top. Disadvantage: - It would doube the work for the moment. Advantage: - Fastest solution. - It gives time to investigate the real problem. Or find a better solution. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Possible broken link: from other.html
Thanks for your additional data. Please can you give me the detailed error message that your browser is indicating at the bottom left (with the yellow !)? Maybe it would help to see the message. Thanks Marcus Am 09/02/2013 01:24 PM, schrieb Marcus (OOo): Thanks for your data. From the values all is fine and the green box should be visible with a link to download the file. Do you have another browser to check if the problem is maybe browser related? Marcus Am 09/01/2013 06:03 PM, schrieb Marcus (OOo): Normally there should a table visible with all possible languages and platforms. If not, it's maybe a problem with the browser. Please try to reload the webpage - also with deleted cache. To see if there is something to improve please give me the output of this webapge (just copypaste the table data): http://www.openoffice.org/download/test/analyze.html Thanks in advance for your help. Marcus Am 09/01/2013 04:54 PM, schrieb Reinhard Richter: Apache OpenOffice Downloads - Official Site - All Builds There is no table with different versions and languages. Cannot download Windows-version zh-cn as required. Coming with a german system and a german Internet Explorer I am offered version de-de only. Need to collect different versions for installation on different PC's in my network. My Internet connection is slow, so I cannot download on each individual PC. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [announce] genLang extract is ready.
On 2 September 2013 20:03, Regina Henschel rb.hensc...@t-online.de wrote: Hi Jan, I have seen, that there is a new project Apache OpenOffice genLang on Pootle and had a look into it for German. 1) I see, that there is a difference in the way file and location is divided compared to the current projects. Is this intended? yes indeed, its one of the major features, less files and directly related to our modules. also remark, no longer 2 project help files are included (allthough empty right now). 2) I see a coding problem for umlauts, for example https://translate.apache.org/**de/aooGenLang4/chart2.po/** translate/#unit=20600974https://translate.apache.org/de/aooGenLang4/chart2.po/translate/#unit=20600974 The same string is correct in the current Pootle project. Thx I will have a look at that, maybe I defined the project wrongly. rgds jan I. Kind regards Regina janI schrieb: Hi I am pleased to inform you, that I have reached a major milestone with genLang. genLang is now integrated in the build system (for extraction), and I have carefully tested that genLang extract (generation of .pot template files) is 100% identical to the existing system (except for the approx 5 errors in the old system). Sources are in branches/l10n40 (based on trunk approx start august) R1519182. The work flow is: 1) run build --all --genPO or build --genPO 2) on pootle server: cd aooGenLang; svn up pootle update_stores (with parms as normal) 3) on translate.a.o update against templates 4) translate 5) on pootle server: pootle sync_stores (with parms as normal) cd aooGenLang; svn commit Now translated files are available in our source tree. I have tested all these steps. We can make a number of elegant optimizations, a) allow committers to commit directly in pootle (removes 5) b) allow committers to run svn up (req. a simple php page and removes 2,3) If someone could review the branch, it would be real nice. Also I need to check build on windows/mac. In the meantime I will integrate genLang convert so we can get all current translations into the new system. and finally integrate genLang merge that generates sources with languages. rgds jan I. --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Example of spreadsheet formula testing
On 27/08/2013 Herbert Duerr wrote: A good idea. I just wrote a task [1] and a script [2] that takes a slightly modified version of Regina's sample document and checks whether all of its tests pass. This script is now part of the Functional Verification Test (a.k.a. FVT). [1] https://issues.apache.org/ooo/show_bug.cgi?id=123119 [2] http://svn.apache.org/r1517802 Really nice stuff! Where's the blog post? Seriously, with this simple framework we make testcase preparation accessible to almost all Calc users, so let's give it the visibility it deserves. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
4.0.1_release_blocker requested: [Bug 123168] Update bundled Spanish (ES) dictionary for Apache OpenOffice 4.0.1
rgb rgb...@apache.org has asked for 4.0.1_release_blocker: Bug 123168: Update bundled Spanish (ES) dictionary for Apache OpenOffice 4.0.1 https://issues.apache.org/ooo/show_bug.cgi?id=123168 --- Additional Comments from rgb rgb...@apache.org Spanish dictionary is now at version 0.7 (AOO 4.0.0 uses version 0.6. Source file at: http://extensions.openoffice.org/project/es_ES-dicts - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [announce] genLang extract is ready.
2013/9/2 janI j...@apache.org On 2 September 2013 20:03, Regina Henschel rb.hensc...@t-online.de wrote: Hi Jan, I have seen, that there is a new project Apache OpenOffice genLang on Pootle and had a look into it for German. 1) I see, that there is a difference in the way file and location is divided compared to the current projects. Is this intended? yes indeed, its one of the major features, less files and directly related to our modules. Good! also remark, no longer 2 project help files are included (allthough empty right now). 2) I see a coding problem for umlauts, for example https://translate.apache.org/**de/aooGenLang4/chart2.po/** translate/#unit=20600974 https://translate.apache.org/de/aooGenLang4/chart2.po/translate/#unit=20600974 The same string is correct in the current Pootle project. Thx I will have a look at that, maybe I defined the project wrongly. I can see the same on ES project. For example, on https://translate.apache.org/es/aooGenLang4/connectivity.po/translate/#unit=20659235 Instead of inválida it says inválida. There are many string like that one. Regards Ricardo rgds jan I. Kind regards Regina janI schrieb: Hi I am pleased to inform you, that I have reached a major milestone with genLang. genLang is now integrated in the build system (for extraction), and I have carefully tested that genLang extract (generation of .pot template files) is 100% identical to the existing system (except for the approx 5 errors in the old system). Sources are in branches/l10n40 (based on trunk approx start august) R1519182. The work flow is: 1) run build --all --genPO or build --genPO 2) on pootle server: cd aooGenLang; svn up pootle update_stores (with parms as normal) 3) on translate.a.o update against templates 4) translate 5) on pootle server: pootle sync_stores (with parms as normal) cd aooGenLang; svn commit Now translated files are available in our source tree. I have tested all these steps. We can make a number of elegant optimizations, a) allow committers to commit directly in pootle (removes 5) b) allow committers to run svn up (req. a simple php page and removes 2,3) If someone could review the branch, it would be real nice. Also I need to check build on windows/mac. In the meantime I will integrate genLang convert so we can get all current translations into the new system. and finally integrate genLang merge that generates sources with languages. rgds jan I. --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [announce] genLang extract is ready.
On 2 September 2013 22:03, Ricardo Berlasso rgb.m...@gmail.com wrote: 2013/9/2 janI j...@apache.org On 2 September 2013 20:03, Regina Henschel rb.hensc...@t-online.de wrote: Hi Jan, I have seen, that there is a new project Apache OpenOffice genLang on Pootle and had a look into it for German. 1) I see, that there is a difference in the way file and location is divided compared to the current projects. Is this intended? yes indeed, its one of the major features, less files and directly related to our modules. Good! also remark, no longer 2 project help files are included (allthough empty right now). 2) I see a coding problem for umlauts, for example https://translate.apache.org/**de/aooGenLang4/chart2.po/** translate/#unit=20600974 https://translate.apache.org/de/aooGenLang4/chart2.po/translate/#unit=20600974 The same string is correct in the current Pootle project. Thx I will have a look at that, maybe I defined the project wrongly. I can see the same on ES project. For example, on https://translate.apache.org/es/aooGenLang4/connectivity.po/translate/#unit=20659235 Instead of inválida it says inválida. There are many string like that I know that I have fun learning spanish, but admitted it does not look right. Now the funny thing is aoo40 PO file: #: conn_shared_res.src#STR_INVALID_COLUMN_NAME_LENGTH.string.text msgid Invalid column name length for column '$columnname$'. msgstr La longitud del nombre de columna es inválida por la columna '$columnname$'. and new connectivity.po file: #: resource/conn_shared_res.src#STR_INVALID_COLUMN_NAME_LENGTH.STRING.TEXT #, fuzzy msgid Invalid column name length for column '$columnname$'. msgstr La longitud del nombre de columna es inválida por la columna '$columnnae$'. So at that level they both look damaged. I am confused. rgds jan I. one. Regards Ricardo rgds jan I. Kind regards Regina janI schrieb: Hi I am pleased to inform you, that I have reached a major milestone with genLang. genLang is now integrated in the build system (for extraction), and I have carefully tested that genLang extract (generation of .pot template files) is 100% identical to the existing system (except for the approx 5 errors in the old system). Sources are in branches/l10n40 (based on trunk approx start august) R1519182. The work flow is: 1) run build --all --genPO or build --genPO 2) on pootle server: cd aooGenLang; svn up pootle update_stores (with parms as normal) 3) on translate.a.o update against templates 4) translate 5) on pootle server: pootle sync_stores (with parms as normal) cd aooGenLang; svn commit Now translated files are available in our source tree. I have tested all these steps. We can make a number of elegant optimizations, a) allow committers to commit directly in pootle (removes 5) b) allow committers to run svn up (req. a simple php page and removes 2,3) If someone could review the branch, it would be real nice. Also I need to check build on windows/mac. In the meantime I will integrate genLang convert so we can get all current translations into the new system. and finally integrate genLang merge that generates sources with languages. rgds jan I. --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Removing JavaScript from other.html
On Mon, Sep 2, 2013 at 1:09 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 09/02/2013 06:51 PM, schrieb Alexandro Colorado: It also looks a bit 'dumb' that we dont have a link to others from the download page within our no script tag: Of course it doesn't make sense to refer to a page with JS when JS is disabled in the broeser. That's why there is no link to the webpage. downloads, need to provide a download link, that is just common sense. There is another problem with othes.html but not offering ANY link, is no solution. Marcus On Mon, Sep 2, 2013 at 11:49 AM, Alexandro Coloradoj...@oooes.org wrote: On 9/2/13, Andrea Pescettipesce...@apache.org wrote: In the last few weeks we've seen users unable to see the big Download button in http://www.openoffice.org/**download/http://www.openoffice.org/download/due to broken (but still used) browsers that failed to parse the JavaScript correctly. And http://www.openoffice.org/**download/other.htmlhttp://www.openoffice.org/download/other.htmlcannot be used as a fallback due to the same issue. The JavaScript in other.html is used only to generate the page content, and the result is independent of the user's browser: as Marcus explained, it is there for convenience in creating the page. How are we using thenoscript tag within others? and which kind of content is it trying to plug? Would it make sense to do the following? 1) Add an All Apache OpenOffice downloads link in the right-hand-side column of http://www.openoffice.org/**download/http://www.openoffice.org/download/near the top: this way, we ensure that browsers with poor JavaScript support still display the link. Problaby the quicker solution, still is just a patch instead of just doing good webdev. 2) Rename other.html to other_js.html This is a bad idea, I've seen many alternative clones being unmantained by webmasters. 3) Modify other.html by pasting the actual download table (can be retrieved, for example, with Firebug from other_js.html) in its HTML. This way we add a manual step (step 3) once per release, but we can be sure that virtually all users can download OpenOffice in all cases (working JavaScript, no JavaScript, broken JavaScript). Regards, Andrea. --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- Alexandro Colorado Apache OpenOffice Contributor http://www.openoffice.org
Re: Removing JavaScript from other.html
Am 09/02/2013 10:33 PM, schrieb Alexandro Colorado: On Mon, Sep 2, 2013 at 1:09 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 09/02/2013 06:51 PM, schrieb Alexandro Colorado: It also looks a bit 'dumb' that we dont have a link to others from the download page within our no script tag: Of course it doesn't make sense to refer to a page with JS when JS is disabled in the broeser. That's why there is no link to the webpage. downloads, need to provide a download link, that is just common sense. There is another problem with othes.html but not offering ANY link, is no solution. Sure, that's the reason why we are discussing how to ensure this for more users than now. Marcus On Mon, Sep 2, 2013 at 11:49 AM, Alexandro Coloradoj...@oooes.org wrote: On 9/2/13, Andrea Pescettipesce...@apache.org wrote: In the last few weeks we've seen users unable to see the big Download button in http://www.openoffice.org/**download/http://www.openoffice.org/download/due to broken (but still used) browsers that failed to parse the JavaScript correctly. And http://www.openoffice.org/**download/other.htmlhttp://www.openoffice.org/download/other.htmlcannot be used as a fallback due to the same issue. The JavaScript in other.html is used only to generate the page content, and the result is independent of the user's browser: as Marcus explained, it is there for convenience in creating the page. How are we using thenoscript tag within others? and which kind of content is it trying to plug? Would it make sense to do the following? 1) Add an All Apache OpenOffice downloads link in the right-hand-side column of http://www.openoffice.org/**download/http://www.openoffice.org/download/near the top: this way, we ensure that browsers with poor JavaScript support still display the link. Problaby the quicker solution, still is just a patch instead of just doing good webdev. 2) Rename other.html to other_js.html This is a bad idea, I've seen many alternative clones being unmantained by webmasters. 3) Modify other.html by pasting the actual download table (can be retrieved, for example, with Firebug from other_js.html) in its HTML. This way we add a manual step (step 3) once per release, but we can be sure that virtually all users can download OpenOffice in all cases (working JavaScript, no JavaScript, broken JavaScript). Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: 4.0.1 release and distribution.
On 01/09/2013 Henk P. Penning wrote: For 4.0.0 I added the binaries slowly ; some 4 to 5 languages a day is what the rsync servers can handle. So, it takes 5 days for the quick mirrors plus 2 days for the straglers. Note that there are some sites that are still trying to catch up. Soon after GA date (or earlier), refs to 4.0.0 sigs and sums should point to 'archive.apache.org/' (instead of www.apache.org). I would very much avoid introducing another bottleneck in the process. Voting on the release already takes 3 days, and we won't start copying anything before we have the final result, as we learned from 4.0. For 4.0, after the release was approved, we managed to have it uploaded to the mirrors (the SF mirrors) rather quickly, and at the same time the checksums/signatures, being very small files, were quickly uploaded to dist. This may have taken 2 days, but not more. With this change we would have 3 days for voting plus 7 days for copying to mirrors before we can announce. And the benefits would be very marginal: the number of users who download from the Apache mirrors is negligible. So, in short, if this can be done in a way that does not slow down the post-approval upload period from 2 days to 7 days, fine; otherwise, it is better to repeat what was done for 4.0: within 2 days binaries on SF and checksums on dist or, even better, already on archive -which is automatically populated from dist but has a 24-hour delay- so that we don't need to update the links later; then, gradually, binaries uploaded to dist too (this time the delay may be a matter of days instead of weeks). Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: 4.0.1 release and distribution.
On 2 September 2013 22:45, Andrea Pescetti pesce...@apache.org wrote: On 01/09/2013 Henk P. Penning wrote: For 4.0.0 I added the binaries slowly ; some 4 to 5 languages a day is what the rsync servers can handle. So, it takes 5 days for the quick mirrors plus 2 days for the straglers. Note that there are some sites that are still trying to catch up. Soon after GA date (or earlier), refs to 4.0.0 sigs and sums should point to 'archive.apache.org/' (instead of www.apache.org). I would very much avoid introducing another bottleneck in the process. Voting on the release already takes 3 days, and we won't start copying anything before we have the final result, as we learned from 4.0. For 4.0, after the release was approved, we managed to have it uploaded to the mirrors (the SF mirrors) rather quickly, and at the same time the checksums/signatures, being very small files, were quickly uploaded to dist. This may have taken 2 days, but not more. With this change we would have 3 days for voting plus 7 days for copying to mirrors before we can announce. And the benefits would be very marginal: the number of users who download from the Apache mirrors is negligible. So, in short, if this can be done in a way that does not slow down the post-approval upload period from 2 days to 7 days, fine; otherwise, it is better to repeat what was done for 4.0: within 2 days binaries on SF and checksums on dist or, even better, already on archive -which is automatically populated from dist but has a 24-hour delay- so that we don't need to update the links later; Are you suggesting pointing users to the archives for current sigs and hashes? If so, I don't think that's a good idea. Note that the main release area (dist) is mirrored in US and EU, whereas AFAIK http://archive.apache.org/dist/ is not. AIUI http://archive.apache.org/dist/ is intended for archives only. Updating the links to point to the archive server should be done for both artifacts and sigs/hashes at the same time. then, gradually, binaries uploaded to dist too (this time the delay may be a matter of days instead of weeks). Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] smaller footprint on dist.
On 2 September 2013 18:26, janI j...@apache.org wrote: On 2 September 2013 15:48, Andrea Pescetti pesce...@apache.org wrote: janI wrote: Would it be possible (and preferable) to make a download page, where the user. a) selected version (exe) b) selected (multiple) languages (language pack without dictionary) c) selected (mutiple) dictionaries. The choices should be combined into a filename == exe+lang(s)+dict(s). Which is sent to the server as a download request. On the server we would have a backend script that packed the items together just like postprocess/instsetoo does today, so the user would get 1 file. Obviously this is not for 4.0.1. What I like of this proposal is that the user still downloads one file, which is optimal for the user interface. A beginning could be to simply assemble the same downloads we have now (i.e., the user has no choice: he will get, say, the Italian version with Italian language and dictionary; only, this will be generated rather than pre-built). Then there are a lot of things to consider: 1) Digital signatures: the assembled installer must respect them, and this seems hard to do. As far as I have been able to find out (with the good help of infra colleagues) is: - Only exe have a digital signature That does not sound right. All other ASF downloads (source archives, binary archives etc) have PGP signatures, which are created by the Release Manager. Or maybe you mean something else by digital signature? meaning this has no impact. But it DO have an impact on checksums, where we need to store all combinations (lots of files, each very small). 2) Server-side processing: this would likely require some load on the mirrors and some infrastructure standardization. I don't know what's the status on Apache mirrors. The server side, processing would happen on our server, and the files would still be located on the mirrors Basically the server side scropt, would split the file request into multiple requests. If our server does the concatenation, surely it will have to intercept all the data from the mirror? That would put a huge network load on the server, no? 3) Respecting the priorities. Apache is a secondary mirror system, since the Apache mirrors don't have enough space/bandwidth to reliably offer downloads. So whatever is done should not cause technical issues with our primary mirror system (SourceForge), that never had space/bandwidth problems. Note that also the Apache Archives never reported problems so far about the space needed to archive old/current releases. The problem is only partial the space itself, much more the size of each release. With a distributed system (like suggested) we can independently release language packs, and the user sees them as integrated in the main AOO release. rgds jan i. Regards, Andrea. --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Removing JavaScript from other.html
AFAICT, there is *already* a really good candidate for the download/other.html page: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds The tables in the middle are easy to follow and AFAIK contain all the required information. No Javascript needed for the table itself. Can't the script which was used to create that content be tweaked a bit to create downloads/other.html? On 2 September 2013 22:26, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 09/02/2013 10:33 PM, schrieb Alexandro Colorado: On Mon, Sep 2, 2013 at 1:09 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 09/02/2013 06:51 PM, schrieb Alexandro Colorado: It also looks a bit 'dumb' that we dont have a link to others from the download page within our no script tag: Of course it doesn't make sense to refer to a page with JS when JS is disabled in the broeser. That's why there is no link to the webpage. downloads, need to provide a download link, that is just common sense. There is another problem with othes.html but not offering ANY link, is no solution. Sure, that's the reason why we are discussing how to ensure this for more users than now. Marcus On Mon, Sep 2, 2013 at 11:49 AM, Alexandro Coloradoj...@oooes.org wrote: On 9/2/13, Andrea Pescettipesce...@apache.org wrote: In the last few weeks we've seen users unable to see the big Download button in http://www.openoffice.org/**download/http://www.openoffice.org/download/due to broken (but still used) browsers that failed to parse the JavaScript correctly. And http://www.openoffice.org/**download/other.htmlhttp://www.openoffice.org/download/other.htmlcannot be used as a fallback due to the same issue. The JavaScript in other.html is used only to generate the page content, and the result is independent of the user's browser: as Marcus explained, it is there for convenience in creating the page. How are we using thenoscript tag within others? and which kind of content is it trying to plug? Would it make sense to do the following? 1) Add an All Apache OpenOffice downloads link in the right-hand-side column of http://www.openoffice.org/**download/http://www.openoffice.org/download/near the top: this way, we ensure that browsers with poor JavaScript support still display the link. Problaby the quicker solution, still is just a patch instead of just doing good webdev. 2) Rename other.html to other_js.html This is a bad idea, I've seen many alternative clones being unmantained by webmasters. 3) Modify other.html by pasting the actual download table (can be retrieved, for example, with Firebug from other_js.html) in its HTML. This way we add a manual step (step 3) once per release, but we can be sure that virtually all users can download OpenOffice in all cases (working JavaScript, no JavaScript, broken JavaScript). Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] smaller footprint on dist.
On Sep 3, 2013 3:13 AM, sebb seb...@gmail.com wrote: On 2 September 2013 18:26, janI j...@apache.org wrote: On 2 September 2013 15:48, Andrea Pescetti pesce...@apache.org wrote: janI wrote: Would it be possible (and preferable) to make a download page, where the user. a) selected version (exe) b) selected (multiple) languages (language pack without dictionary) c) selected (mutiple) dictionaries. The choices should be combined into a filename == exe+lang(s)+dict(s). Which is sent to the server as a download request. On the server we would have a backend script that packed the items together just like postprocess/instsetoo does today, so the user would get 1 file. Obviously this is not for 4.0.1. What I like of this proposal is that the user still downloads one file, which is optimal for the user interface. A beginning could be to simply assemble the same downloads we have now (i.e., the user has no choice: he will get, say, the Italian version with Italian language and dictionary; only, this will be generated rather than pre-built). Then there are a lot of things to consider: 1) Digital signatures: the assembled installer must respect them, and this seems hard to do. As far as I have been able to find out (with the good help of infra colleagues) is: - Only exe have a digital signature That does not sound right. All other ASF downloads (source archives, binary archives etc) have PGP signatures, which are created by the Release Manager. Or maybe you mean something else by digital signature? yes signing with a certificate. pgp is at level with mds/sha5. meaning this has no impact. But it DO have an impact on checksums, where we need to store all combinations (lots of files, each very small). 2) Server-side processing: this would likely require some load on the mirrors and some infrastructure standardization. I don't know what's the status on Apache mirrors. The server side, processing would happen on our server, and the files would still be located on the mirrors Basically the server side scropt, would split the file request into multiple requests. If our server does the concatenation, surely it will have to intercept all the data from the mirror? That would put a huge network load on the server, no? depending how you make it. rgds jan i 3) Respecting the priorities. Apache is a secondary mirror system, since the Apache mirrors don't have enough space/bandwidth to reliably offer downloads. So whatever is done should not cause technical issues with our primary mirror system (SourceForge), that never had space/bandwidth problems. Note that also the Apache Archives never reported problems so far about the space needed to archive old/current releases. The problem is only partial the space itself, much more the size of each release. With a distributed system (like suggested) we can independently release language packs, and the user sees them as integrated in the main AOO release. rgds jan i. Regards, Andrea. --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A question about StarBasic
Juergen, Yes SAPGUI is not an AOO default object, it should be a SAP COMM object. Do you mean OpenOffice Basic doesn't support non-default objects? If so, what are the OpenOffice Basic default objects? Clarence 2013/9/2 Jürgen Schmidt jogischm...@gmail.com On 9/2/13 11:09 AM, Clarence GUO wrote: Thanks Peter, Yes Set SapGuiAuto = CreateObject(Excel.Sheet) works. Why SAPGUI must be an ActiveXObject? Is it by design? whatever it is in detail it is not part of AOO by default and probably comes from somewhere else. Juergen Clarence 2013/9/2 Peter Eberlein pet@refofd.verwalt-berlin.de Hi Clarence, Am 02.09.2013 08:47, schrieb Clarence GUO: Hi~ I'm totally green at StarBasic and VBA. Now I have a question about CreateObject. I installed SAP and have below macros. Dim SapGuiAuto As Variant Set SapGuiAuto = CreateObject(SAPGUI) SAPGUI must be an ActiveXObject. Does Set SapGuiAuto = CreateObject(Excel.Sheet) work? Regards Peter --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
