Re: Yes. You can do this with OpenOffice. (MysteryGuitarMan video with OpenOffice Mac)
Well, this came to my mind: I do not know if the author draw this motion picture cell by cell, but I could write a UNO program to do that, and it shall take less than a couple of hours to generate that kind of stop motion video. This is not hard. Maybe this can be my next topic to submit to the local conference about using OpenOffice UNO API. This is cool~ On 2012/08/12 00:47, Rob Weir said: > On Fri, Aug 10, 2012 at 6:39 PM, Rob Weir wrote: >> On Fri, Aug 10, 2012 at 6:06 PM, Andreas Säger wrote: >>> Am 10.08.2012 02:24, Rob Weir wrote: And here is the "behind the scenes" video that explains how he did it: http://www.youtube.com/watch?v=6PCTinsZ7dM >>> >>> Having a video converter which creates the coarse pixel frames, all you need >>> is one matrix of color values per frame and script to dump them into the >>> Calc document. >>> >>> Matrix of 16 colors calculated from 32x32 random values: http://www.mediafire.com/file/zfw69gddrcwacoc/PixelMatrix.ods >>> >> >> Cool. How would we get the pixel level numeric data into the >> spreadsheet initially? I assume there is nothing in the macro >> language that can parse image data at that level. So we'd need to call >> out to a helper library? >> >> Also, one other nice time to have -- not strictly necessary, but would >> improve the results -- picking an optimal color palette that best >> matches the colors in the original image. There are some standard >> algorithms for this: http://en.wikipedia.org/wiki/Color_quantization >> > > Is there any interest in making a more formal contest out of this? > > I don't know what we can offer the winner other then eternal fame and > glory, but a contest could look like this: > > 1) Goal is to using OpenOffice Calc to automate conversion of a given > image into cell-based artwork, using background colors. Variable > character data in cells may also be used (optional) as an > anti-aliasing technique. > > 2) Code would need to be based on AOO Calc 3.4.0, using > macros/scripts. Calls to external non script code would be permitted > only for the initial extraction of pixel data from the image. All > code would need to be made available for the judges to review. > > 3) Some images would be provided in advance. Others images would be > unknown to the contestants and would be run only after the code was > submitted. > > 4) Judges would score all submissions based on rendering quality, > speed and technical elegance. > > If there is interest, I can work with a subset of interested parties > to define this further. We'd do that in private, and of course those > who define the contest or judge it would be ineligible for > participating int he contest. > > If something like this could be done, do we think there would be any interest? > > -Rob > > > > > > > > > >> -Rob >> >>> >>> -- Best regards, imacat ^_*' PGP Key http://www.imacat.idv.tw/me/pgpkey.asc <> News: http://www.wov.idv.tw/ Tavern IMACAT's http://www.imacat.idv.tw/ Woman in FOSS in Taiwan http://wofoss.blogspot.com/ Apache OpenOffice http://www.openoffice.org/ EducOO/OOo4Kids Taiwan http://www.educoo.tw/ signature.asc Description: OpenPGP digital signature
Re: CMS diff: Apache OpenOffice - 开放免费的文字处理软件
Thanks Joe & Kay, I translated zh-cn/why/why_great and zh-cn/why/why_free . This time I see the status of "M". I guess the conflict was resolved. Thanks! - Shenfeng 2012/8/11 Joe Schaefer > No a clear status like that is the green light > for more edits. Please proceed. > > > > > > > > > From: Shenfeng Liu > >To: ooo-dev@incubator.apache.org > >Sent: Friday, August 10, 2012 1:22 AM > >Subject: Re: CMS diff: Apache OpenOffice - 开放免费的文字处理软件 > > > >I did a revert for the tree. And now there is no M__+ on any file or R_+_C > >on directory. So... should I wait for any of your action before I edit any > >page? > > > >- Shenfeng > > > > > >2012/8/10 Shenfeng Liu > > > >> Joe, > >> You are right that is was exactly what I did: I copied the tree /why > to > >> /zh-cn/. Then I immediately edited one page, thinking the changes can be > >> committed in a batch... Sorry that it caused a mess as a result... > >> Let me try if I can make a Revert or Update to fix it... > >> Thanks very much for your help! > >> > >> - Shenfeng > >> > >> > >> > >> > >> 2012/8/10 Kay Schenk > >> > >>> On Thu, Aug 9, 2012 at 12:33 PM, Joe Schaefer >>> >wrote: > >>> > >>> > No I'm not saying that at all. Here is the documentation > >>> > I just finished writing about this: > >>> > > >>> > http://www.apache.org/dev/cmsref#anonymous-add > >>> > > >>> > > >>> > > >>> > > >>> OK...hopefully this addition will help. > >>> > >>> > >>> > > >>> > > > >>> > > From: Kay Schenk > >>> > >To: ooo-dev@incubator.apache.org; Joe Schaefer < > joe_schae...@yahoo.com > >>> > > >>> > >Sent: Thursday, August 9, 2012 3:31 PM > >>> > >Subject: Re: CMS diff: Apache OpenOffice - 开放免费的文字处理软件 > >>> > > > >>> > >On Thu, Aug 9, 2012 at 11:23 AM, Joe Schaefer < > joe_schae...@yahoo.com > >>> > >wrote: > >>> > > > >>> > >> I believe the situation goes like this: > >>> > >> > >>> > >> Shenfeng creates that directory as a copy > >>> > >> of some other directory as the CMS anon user > >>> > >> and someone committed that change. Then > >>> > >> instead of updating the anon user tree and dealing > >>> > >> with the directory conflict by reverting the directory > >>> > >> add and pulling it from the server, he simply went > >>> > >> ahead and edited the files in the directory, which > >>> > >> were now sitting in a directory with a conflict marker > >>> > >> on it. That's why clones of the anon user's working copy > >>> > >> fail to be able to commit from. > >>> > >> > >>> > >> The only way to fix this is to revert the directory > >>> > >> as the anon user, and redo the changes. Otherwise > >>> > >> you will need to apply the patches sent to the mailing > >>> > >> list to a local checkout of that directory and commit > >>> > >> them. > >>> > >> > >>> > >> Because of the way the CMS deals with anonymous working > >>> > >> copies, and the way svn deals with newly committed directories, > >>> > >> you will always run into problems applying directory additions > >>> > >> from an anonymous clone. I will probably need to document > >>> > >> the steps required on the cmsref page because the anon user > >>> > >> needs to revert those changes before continuing on and editing > >>> > >> the directory's contents. > >>> > >> > >>> > >> > >>> > >> > >>> > >Ok, just so we're clear on this. > >>> > > > >>> > >It sort of sounds like requests for new directories shouldn't be > made > >>> > >through the CMS at all, but explicity requested *first*, and added > by a > >>> > >commtter through client svn. Yes? > >>> > > > >>> > > > >>> > > > >>> > >> > >>> > >> > > >>> > >> > From: Kay Schenk > >>> > >> >To: ooo-dev@incubator.apache.org > >>> > >> >Sent: Thursday, August 9, 2012 2:08 PM > >>> > >> >Subject: Re: CMS diff: Apache OpenOffice - 开放免费的文字处理软件 > >>> > >> > > >>> > >> >Hi Joe, Michal and Shenfeng-- > >>> > >> > > >>> > >> >On 08/09/2012 11:03 AM, Joe Schaefer wrote: > >>> > >> >> I just published the site without issue- there > >>> > >> >> must be a language barrier here we need to overcome. > >>> > >> >> > >>> > >> >> Technically there are 3 seperate steps involved in editing > >>> > >> >> a page: > >>> > >> >> > >>> > >> >> 1) submitting your changes to the cms > >>> > >> >> > >>> > >> >> 2) telling the cms to commit your changes > >>> > >> >> > >>> > >> >> 3) publishing the site > >>> > >> >> > >>> > >> >> (1 and 3) are almost never a problem, but (2) might be > >>> > >> >> because of the status of a file or directory in the working > >>> > >> >> copy being inconflict with that of the server (somestatus > >>> > >> >> other than "M"). > >>> > >> > > >>> > >> >After Michal said the other day (Tues) that he couldn't do a > commit > >>> on > >>> > >> >the recent changes Shenfeng made to the "why" area, I tried this > >>> also > >>> > >> >(from the CMS bookmarklet) with the same results -- conflicts > >>> needed to > >>> > >> >be resolved. So no commit, no publish. > >>
CMS diff: Why Apache OpenOffice: Free software
Clone URL (Committers only):
https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://ooo-site.apache.org/zh-cn%2Fwhy%2Fwhy_free.mdtext
Shenfeng Liu
Index: trunk/content/zh-cn/why/why_free.mdtext
===
--- trunk/content/zh-cn/why/why_free.mdtext (revision 1372039)
+++ trunk/content/zh-cn/why/why_free.mdtext (working copy)
@@ -1,4 +1,4 @@
-Title: Why Apache OpenOffice: Free software
+Title: 为何选择Apache OpenOffice：免费软件
Notice:Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
@@ -16,18 +16,18 @@
specific language governing permissions and limitations
under the License.
- #
{.rfloatimg}
+ # {.rfloatimg}
-Apache OpenOffice is free software. That means you are free to download it,
free to install it on as many PCs as you like, free to pass copies to as many
people as you like. You may use OpenOffice for any purpose without restriction:
private, educational, public administration, commercial... Free, really free.
+Apache
OpenOffice是一款免费软件。这意味着你可以免费下载，免费安装到任意数量的电脑上，随意将这款软件复制给其他人。你可以将OpenOffice使用于任何目的而无限制：个人，教育，公务，商务……真正的免费，真正的自由。
- - **Free of charge**
+ - **没有费用**
-It's hard to believe that high quality, easy to use software like Apache
OpenOffice can really be free. But thanks to contributions of time and money,
from individuals and companies (large and small), OpenOffice is free for you to
use today. Furthermore, the open-source licence used by OpenOffice means this
freedom can never be taken away. The OpenOffice community are delighted if you
find our software of use. Please help us by telling people about Apache
OpenOffice, and if you can, pass them on a copy. More people use OpenOffice as
a result of personal recommendation than any other route.
+很难相信象Apache
OpenOffice这样的高质量、易用软件会是真正免费的。但要感谢那些个人与公司（无论大小）的贡献者所投入的精力与资金，OpenOffice如今可以供你免费自由使用。而且，OpenOffice所使用的开源协议保证了这种使用的自由永远不会被剥夺。请帮助我们将Apache
OpenOffice告诉更多的人，而且如果可以，给他们一份拷贝。因为相对于其它途径，更多的人是因为他人的推荐而使用OpenOffice的。
- - **Freedom from worry**
+ - **免除顾虑**
-However, a free software licence means much more than a one-off cost
saving. It means you never need worry again whether your software is legal, or
whether it will expire some day. For people responsible for a number of
computers - from just a few in a small business, hundreds in a school,
thousands in a corporation - this is a huge weight off the mind. No need for
software audits, for keeping invoices for years, no worry about ending up in
court because you misread some small print in a licence agreement.
+
并且，一个免费的软件协议所意味的不仅仅是一次花费的节省。它意味着你永远不用再担心你的软件是否合法，或者它是否会在某一天过期。对于那些负责多台计算机——从小公司的几台，到学校的几百台，到一个大型企业的几千台——的人来说，这真是大大省了心了。不用进行软件审查，不用把发票存好几年，不必担心因为误读了许可协议中某一小段而最后上法庭。
- - **We value your freedom**
+ - **自由选择**
-As part of a community dedicated to free software, we also value your
freedom of choice. Apache OpenOffice will read and write files which can be
used in other common office software. It was the first software in the world to
fully support the ISO standard for office file formats which is being adopted
by a growing number of software vendors. If you want to use other software, we
want you to be free to do so. If you want to change your PC from Microsoft
Windows to Apple Mac to Linux, we want you to be free to do so. If you like
this approach, feel free to join the Apache OpenOffice community.
+作为致力于免费软件的社区，我们同样为你选择的自由而努力。Apache
OpenOffice可以读写同样能够被其它常用办公软件使用的文件。它是世界上第一个完全支持ISO办公文件格式标准的软件，而这一标准正在被越来越多的软件商所支持。如果你想使用其它软件，我们希望你可以毫无困难地做到。如果你想把自己的电脑从微软视窗改变到苹果Mac或Linux，我们希望你可以毫无困难地做到。如果你喜欢这个主意，来加入Apache
OpenOffice社区吧。
CMS diff: Why Apache OpenOffice: Great Software
Clone URL (Committers only):
https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://ooo-site.apache.org/zh-cn%2Fwhy%2Fwhy_great.mdtext
Shenfeng Liu
Index: trunk/content/zh-cn/why/why_great.mdtext
===
--- trunk/content/zh-cn/why/why_great.mdtext(revision 1372039)
+++ trunk/content/zh-cn/why/why_great.mdtext(working copy)
@@ -1,4 +1,4 @@
-Title: Why Apache OpenOffice: Great Software
+Title: 为何选择Apache OpenOffice：杰出的软件
Notice:Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
@@ -16,18 +16,18 @@
specific language governing permissions and limitations
under the License.
- #
{.rfloatimg}
+ # {.rfloatimg}
-Great Software requires great people. Apache OpenOffice is the result of over
twenty years' continuous high quality software engineering. Designed from the
start as a **single piece of software**, Apache OpenOffice has a consistency
and a quality that is world class. Its **open-source** development model means
there are no secrets.
+杰出的软件依赖于杰出的人。Apache OpenOffice凝聚了二十多年持续高质量软件工程的结晶。从最初的**一体软件**开始，Apache
OpenOffice秉承一致，具有世界级的质量。它的**开源**开发模式意味着没有秘密。
- - **Better by design**
+ - **更好的设计**
-Developed over twenty years, Apache OpenOffice is a mature, reliable,
product. OpenOffice was designed from the start as a single piece of software -
not bolted together from separate software packages. This makes it very
consistent and easy to use - what you learn in one application is immediately
usable in another. The context-sensitive help works across all applications,
unobtrusively providing the precise help you need. You can even open any type
of document from any application - OpenOffice is really one piece of software.
It also runs on all major computing platforms - Microsoft Windows, GNU/Linux,
Sun Solaris, Apple Mac - isn't that great!
+历经二十余年开发，Apache
OpenOffice是一款成熟可靠的产品。OpenOffice是从单一的一体软件为设计起点——而不是将来自不同地方的软件包囫囵拼装到一起。这使它非常一致并易于使用——你在一个应用中学到的能够立即应用到另一个应用。在所有应用中都有基于上下文的帮助，恰到好处地为你提供所需的精确帮助信息。你甚至可以在任何一个应用中打开任何一种类型的文档——这就叫一体软件。并且它可以在所有主要计算机平台上运行——微软视窗、GNU/Linux、Sun
Solaris、苹果Mac——是不是很棒！
- - **Better for you**
+ - **更适合你**
-Apache OpenOffice contains all the office software you need, in one single
package. You don't have to worry which version to install: one installation
program provides everything. The installation also includes features which some
expensive rivals do not - for example, the ability to create .pdf files when
you want to guarantee what the recipient sees on their computer. There is also
a growing range of extensions: additional features that any developer can
provide. The Apache OpenOffice project releases software several times a year
so you can take advantage of new features as quickly as possible.
+Apache
OpenOffice在一个单一软件包中包含了所有你需要的办公软件。你不必苦恼于应选择安装什么：一个安装程序就包含了所有应用。所安装的内容中还包含一些那些昂贵的竞争对手所没有的功能——比如，创建pdf文件的功能，使你能够确保文件接收者可以在它们的机器上浏览你的文件。而大量的扩展包提供了许多额外的功能，这样的扩展包来自不同的开发者，而且还在不断增加。Apache
OpenOffice项目每年会发布多个版本，这样你就能够尽快享受到新的功能。
- - **Honest software**
+ - **诚信软件**
-Apache OpenOffice is developed using an open-software, "no secrets"
approach. Anyone can look at the programs and suggest improvements, or fix
bugs. Anyone can report problems or request enhancements, and anyone can see
the response from other users or developers. The status of current and future
releases is displayed on a public wiki, so you can decide if and when you want
to upgrade to take advantage of new features. Anyone used to commercial
software and its hyping and marketing speak will find Apache OpenOffice
refreshingly different. Enjoy the benefits of open-source!
+Apache
OpenOffice是使用开放软件开发的，遵循“没有秘密”的方式。任何人都可以查看这个项目并提出改进建议或修复缺陷。任何人都可以报告问题或者提出功能增强的要求，并看到来自其他用户或开发员的反馈。当前和未来版本都在wiki页面公布，这样你就可以决定是否想升级以利用新功能，何时升级。所有习惯于商业软件和相关市场宣传和广告的人都会发现Apache
OpenOffice完全不同。享受开源之美吧！
RE: ODF angle in draw:transform are in degrees
@Regina, Thanks. I agree that the transform case needs to be taken up also. My sense is that there is agreement that there should be transposition to SVG with attention to migration and down-level compatibility issues. I also agree that the situation with existing ODF 1.0/../1.2 documents and implementations must be clarified, where practical, with advisories and errata. - Dennis -Original Message- From: Regina Henschel [mailto:rb.hensc...@t-online.de] Sent: Saturday, August 11, 2012 10:33 To: ooo-dev@incubator.apache.org; LO-dev Subject: Re: ODF angle in draw:transform are in degrees Hi Dennis, [ ... ] That is the problem with the unit of angles for gradients. But this here is different. It is about transformations. The matrix has no problems, because the relevant matrix elements are used as unitless factor. But rotate, skewX and skewY have angles as parameter. > > The next step is to come up with a new attribute (or attributes) that > correspond to SVG provisions and are rigorously defined. The new > attribute(s) would appear down-level (i.e., in ODF > 1.0/1.1/IS26300/1.2) as extensions and be ignored but be official in > ODF 1.3 (which would deprecate but not remove draw:angle). > > If the SVG-aligned attributes are present (and to be required in ODF > 1.3 documents, let's say) and recognized, they would over-rule > draw:angle. ODF 1.3 Producers that wanted to ensure down-level > interoperability would produce both attributes. > > How does that sound? It would be great to have an attribute svg:transform. That would be the best solution for me and will prevent further trouble. Nevertheless the problem remains, that ODF1.1 has no unit at all and documents written by StarOffice use unit rad, and ODF1.2 specifies degree, but at least Apache OpenOffice, LibreOffice and Powerpoint 2013 use rad. I don't know, whether Gnumeric uses . I have seen in the meantime that Genumeric uses the attribute in fillings in charts and unfortunately (from Apache OpenOffice point of view) Gnumeric uses it in deg there and not 0.1deg. So there are some rules or hints needed, how to tread documents which are ODF1.1 or ODF1.2. Kind regards Regina [ ... ]
Re: ODF angle in draw:transform are in degrees
Hi Dennis, Dennis E. Hamilton schrieb: The proposal that Regina brought to the ODF TC is safer. It does not depend on attempting to identify the producer. (In fact, the ODF specification says that the generator identification is *not* to be used in this manner. It is also unreliably used.) The idea is to face reality and affirm that draw:angle has an integer value that expresses the angle in units of 1/10-th degree. (There are other aspects of this problem that are not so clean cut.) This supports alignment on the present reality and preserves the interoperability that is afforded with that treatment. That is the problem with the unit of angles for gradients. But this here is different. It is about transformations. The matrix has no problems, because the relevant matrix elements are used as unitless factor. But rotate, skewX and skewY have angles as parameter. The next step is to come up with a new attribute (or attributes) that correspond to SVG provisions and are rigorously defined. The new attribute(s) would appear down-level (i.e., in ODF 1.0/1.1/IS26300/1.2) as extensions and be ignored but be official in ODF 1.3 (which would deprecate but not remove draw:angle). If the SVG-aligned attributes are present (and to be required in ODF 1.3 documents, let's say) and recognized, they would over-rule draw:angle. ODF 1.3 Producers that wanted to ensure down-level interoperability would produce both attributes. How does that sound? It would be great to have an attribute svg:transform. That would be the best solution for me and will prevent further trouble. Nevertheless the problem remains, that ODF1.1 has no unit at all and documents written by StarOffice use unit rad, and ODF1.2 specifies degree, but at least Apache OpenOffice, LibreOffice and Powerpoint 2013 use rad. I don't know, whether Gnumeric uses . I have seen in the meantime that Genumeric uses the attribute in fillings in charts and unfortunately (from Apache OpenOffice point of view) Gnumeric uses it in deg there and not 0.1deg. So there are some rules or hints needed, how to tread documents which are ODF1.1 or ODF1.2. Kind regards Regina - Dennis -Original Message- From: libreoffice-bounces+dennis.hamilton=acm@lists.freedesktop.org [mailto:libreoffice-bounces+dennis.hamilton=acm@lists.freedesktop.org] On Behalf Of Noel Grandin Sent: Friday, August 10, 2012 23:58 To: Apache OpenOffice dev Cc: LO-dev Subject: Re: ODF angle in draw:transform are in degrees One way would be to add a new attribute specifying either degrees or radians. Then modify the loader code so it looks at the application that created the file to determine what it should do in cases where there is not attribute. Fundamentally, I don't see that there is a "perfect" solution to this. On Thu, Aug 9, 2012 at 3:41 PM, Regina Henschel wrote: Hi, there is a problem which I have not addressed in the Wiki (see other mail). As far as I see, the specification ODF 1.1 has no setting for the unit of the angles, but ODF 1.2 set it to "degrees". SVG has it in degrees too, so this setting is reasonable. But our implementation uses "radians". So there are a lot of documents out, that have the angle in radians in the document. Any idea how to proceed? Kind regards Regina ___ LibreOffice mailing list libreoff...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list libreoff...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Yes. You can do this with OpenOffice. (MysteryGuitarMan video with OpenOffice Mac)
On Fri, Aug 10, 2012 at 6:39 PM, Rob Weir wrote: > On Fri, Aug 10, 2012 at 6:06 PM, Andreas Säger wrote: >> Am 10.08.2012 02:24, Rob Weir wrote: >>> >>> >>> And here is the "behind the scenes" video that explains how he did it: >>> >>> http://www.youtube.com/watch?v=6PCTinsZ7dM >>> >> >> Having a video converter which creates the coarse pixel frames, all you need >> is one matrix of color values per frame and script to dump them into the >> Calc document. >> >> Matrix of 16 colors calculated from 32x32 random values: >>> >>> http://www.mediafire.com/file/zfw69gddrcwacoc/PixelMatrix.ods >> > > Cool. How would we get the pixel level numeric data into the > spreadsheet initially? I assume there is nothing in the macro > language that can parse image data at that level. So we'd need to call > out to a helper library? > > Also, one other nice time to have -- not strictly necessary, but would > improve the results -- picking an optimal color palette that best > matches the colors in the original image. There are some standard > algorithms for this: http://en.wikipedia.org/wiki/Color_quantization > Is there any interest in making a more formal contest out of this? I don't know what we can offer the winner other then eternal fame and glory, but a contest could look like this: 1) Goal is to using OpenOffice Calc to automate conversion of a given image into cell-based artwork, using background colors. Variable character data in cells may also be used (optional) as an anti-aliasing technique. 2) Code would need to be based on AOO Calc 3.4.0, using macros/scripts. Calls to external non script code would be permitted only for the initial extraction of pixel data from the image. All code would need to be made available for the judges to review. 3) Some images would be provided in advance. Others images would be unknown to the contestants and would be run only after the code was submitted. 4) Judges would score all submissions based on rendering quality, speed and technical elegance. If there is interest, I can work with a subset of interested parties to define this further. We'd do that in private, and of course those who define the contest or judge it would be ineligible for participating int he contest. If something like this could be done, do we think there would be any interest? -Rob > -Rob > >> >>
RE: ODF angle in draw:transform are in degrees
The proposal that Regina brought to the ODF TC is safer. It does not depend on attempting to identify the producer. (In fact, the ODF specification says that the generator identification is *not* to be used in this manner. It is also unreliably used.) The idea is to face reality and affirm that draw:angle has an integer value that expresses the angle in units of 1/10-th degree. (There are other aspects of this problem that are not so clean cut.) This supports alignment on the present reality and preserves the interoperability that is afforded with that treatment. The next step is to come up with a new attribute (or attributes) that correspond to SVG provisions and are rigorously defined. The new attribute(s) would appear down-level (i.e., in ODF 1.0/1.1/IS26300/1.2) as extensions and be ignored but be official in ODF 1.3 (which would deprecate but not remove draw:angle). If the SVG-aligned attributes are present (and to be required in ODF 1.3 documents, let's say) and recognized, they would over-rule draw:angle. ODF 1.3 Producers that wanted to ensure down-level interoperability would produce both attributes. How does that sound? - Dennis -Original Message- From: libreoffice-bounces+dennis.hamilton=acm@lists.freedesktop.org [mailto:libreoffice-bounces+dennis.hamilton=acm@lists.freedesktop.org] On Behalf Of Noel Grandin Sent: Friday, August 10, 2012 23:58 To: Apache OpenOffice dev Cc: LO-dev Subject: Re: ODF angle in draw:transform are in degrees One way would be to add a new attribute specifying either degrees or radians. Then modify the loader code so it looks at the application that created the file to determine what it should do in cases where there is not attribute. Fundamentally, I don't see that there is a "perfect" solution to this. On Thu, Aug 9, 2012 at 3:41 PM, Regina Henschel wrote: > Hi, > > there is a problem which I have not addressed in the Wiki (see other mail). > As far as I see, the specification ODF 1.1 has no setting for the unit of > the angles, but ODF 1.2 set it to "degrees". SVG has it in degrees too, so > this setting is reasonable. > > But our implementation uses "radians". So there are a lot of documents out, > that have the angle in radians in the document. > > Any idea how to proceed? > > Kind regards > Regina > > ___ > LibreOffice mailing list > libreoff...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list libreoff...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Yes. You can do this with OpenOffice. (MysteryGuitarMan video with OpenOffice Mac)
Hi. 2012/8/9 Rob Weir : > If you don't know this guy's work you should really check it out. He > has over 2 million YouTube subscribers. It is hard to describe, but > I'd say it is 1/3 one-man band, 1/3 stop motion animation, 1/3 green > screen work. And 100% fun. > > https://www.youtube.com/user/MysteryGuitarMan > > His latest video is called "Stop-Motion Excel". But if you look > closely you see that he is actually using OpenOffice for the Mac: > > https://www.youtube.com/watch?v=Fq9EV2fYF2E > > And here is the "behind the scenes" video that explains how he did it: > > http://www.youtube.com/watch?v=6PCTinsZ7dM > > This is a fun video and good for showing friends and family what you > are working on. Let's try to get the world out, via the social > networking site, both project's and personal. And if you want to add > a comment to the YouTube post pointing out that this is OpenOffice and > it can be downloaded for free from www.openoffice.org, then great! > This is a good way to introduce the product to more users. > > Bonus points for adapting an old ASCII Art algorithm to generate a > spreadsheet from a photo. If anyone can do that I'll interview them > for a blog post and show of their work. > > Regards, > > -Rob So Good! Albino
Re: svn commit: r1367858 - in /incubator/ooo/trunk/main/pyuno/source/module: pyuno.cxx pyuno_callable.cxx pyuno_module.cxx pyuno_runtime.cxx
Hi again; This is weird. According to: http://python3porting.com/cextensions.html Python 2.6 and 2.7 should support PyVarObject_HEAD_INIT In any case, I added the backward compatibility as documented in that site. Committed revision as 1371957. Thanks! Pedro. > > From: Pavel Janík >To: Pedro Giffuni >Cc: ooo-dev@incubator.apache.org >Sent: Saturday, August 11, 2012 12:45 AM >Subject: Re: R: Re: svn commit: r1367858 - in >/incubator/ooo/trunk/main/pyuno/source/module: pyuno.cxx pyuno_callable.cxx >pyuno_module.cxx pyuno_runtime.cxx > > >On Aug 11, 2012, at 7:34 AM, Pedro Giffuni wrote: > >> Ugh ... >> >> Just another thing: perhaps you are using the system python and it happens >> to be <= 2.5 ? > >No. I use system Python, but it is > >Pavel-Janiks-MacBook-Pro:~ pavel$ python >Python 2.6.1 (r261:67515, Aug 2 2010, 20:10:18) >[GCC 4.2.1 (Apple Inc. build 5646)] on darwin >Type "help", "copyright", "credits" or "license" for more information. ^D >Pavel-Janiks-MacBook-Pro:~ pavel$ > >The default Python on 10.6.8. > >> I can add backward compatibility for this case rather easily but sooner or >> later you may run into trouble as we are preparing for system Python3 and it >> removed some deprecated functionality. > >Yup, but we still have to support Snow Leopard now. >-- >Pavel Janík > > > > > >
Fwd: ApacheCon Europe CFP closes Monday!
Cross posting to ensure everyone in Apache OpenOffice is not unaware that the CFP system will close for ApacheCon Europe on Monday. It's August, it's summer for some of us, and it's the weekend, but this is your best chance to get your submission reviewed. I'll come on the list with some additional proposals to flesh out our programme tomorrow. Right now, I have to barbecue some pork ribs for a big birthday celebration. My step-father is 98! :) /don -- Forwarded message -- From: Nick Burch Date: Sat, Aug 11, 2012 at 5:32 AM Subject: ApacheCon Europe CFP closes Monday! To: committ...@apache.org Hi All I know that for many of you, it's a lovely summer's weekend, and the last of the Olympics are on... Despite these distractions, please don't forget, the Call For Papers for ApacheCon Europe closes on Monday! For the list of planned tracks, and instructions on how to submit your talks, please see http://www.apachecon.eu/cfp/ Thanks Nick
Re: Extensions and Templates New Features
2012/8/9 Roberto Galoppini : > Below what's new, I also blogged about that at SourceForge blog. > > 1) Download statistics are now automatically obtained via the > SourceForge API and are more reliable than the old system, in which > the counters had been turned off and remained stuck for a long time > due to inaccuracies in the counting procedures and incompatibilities > with cache system. By the way, the SourceForge API is the same system > used for the official Apache OpenOffice counter downloads. > Additionally, since we can’t calculate statistics for externally > hosted extensions as reliably, their download counters have been > removed and they won’t appear in the “Most Popular Extensions” > listings. This is also the case for Commercial extensions with no > public releases. Note that the default home page of the Extensions > site has been set back to "Most Popular Extensions", as we believe > that newcomers would probably benefit from having the top extensions > in the home page. To provide visitors only meaningful statistics, the > daily download numbers have been replaced by a link to a timeline with > real-time statistics, charts and analysis. > > 2) The new antispam system is now online on the Extensions site. We’ve > tested it extensively. Since the live site receives up to 50 spam > submissions per day it was pretty easy to figure out if it was working > properly. It has been in operation for over a week and so far has > proved very effective. For end-users this means meaningful comments > are more visible and the possibility of adding comments if needed > (something we had to temporarily block for some titles because of the > spam). > > 3) We updated the graphic theme of the site and the primary links to > reflect the new name and new logo for Apache OpenOffice. In this way > visitors can more easily identify these sites as the official > repositories of OpenOffice Extensions and Templates, and they can be > confident that they are still maintained. > > Roberto > > -- > > This e- mail message is intended only for the named recipient(s) above. It > may contain confidential and privileged information. If you are not the > intended recipient you are hereby notified that any dissemination, > distribution or copying of this e-mail and any attachment(s) is strictly > prohibited. If you have received this e-mail in error, please immediately > notify the sender by replying to this e-mail and delete the message and any > attachment(s) from your system. Thank you. > Great news! The spam disappeared from the site. A quick question: which is the best way for an user to report problems found on the site? Regards Ricardo
Re: ODF angle in draw:transform are in degrees
One way would be to add a new attribute specifying either degrees or radians. Then modify the loader code so it looks at the application that created the file to determine what it should do in cases where there is not attribute. Fundamentally, I don't see that there is a "perfect" solution to this. On Thu, Aug 9, 2012 at 3:41 PM, Regina Henschel wrote: > Hi, > > there is a problem which I have not addressed in the Wiki (see other mail). > As far as I see, the specification ODF 1.1 has no setting for the unit of > the angles, but ODF 1.2 set it to "degrees". SVG has it in degrees too, so > this setting is reasonable. > > But our implementation uses "radians". So there are a lot of documents out, > that have the angle in radians in the document. > > Any idea how to proceed? > > Kind regards > Regina > > ___ > LibreOffice mailing list > libreoff...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice
