Re: [xwiki-users] Users not displayed
Hi Niels, many thanks for your answer. However I am not sure I understood everything. What I actually would like to know is what should I do to solve this critical problem? How should I edit the http://xwiki:8080/xwiki/bin/edit/XWiki/XWikiAllGroup?editor=object for instance? We are using one and only one XWiki, no virtual ones (if I got it right, virtual wikis allows you to create/use more than one XWiki instance). I also tried to re-import the XAR file logged as administrator. The problem still persists. I forgot to mention it: we are using XWiki Enterprise 1.9.2.22089. So not the milestone one. This problem is quite critical and decisive for us. I installed XWiki locally on my machine with a PostgreSQL database and things work fluently. I do not understand why this does not work on this Linux machine and with a MySQL database. Do you think this is a question of right permissions? I wish you a wonderful day. Cheers, christian -- Canoo - Your Solution Provider for Rich Internet Applications Christian Ribeaud Canoo Engineering AG Kirschgartenstrasse 5 CH-4051 Basel Tel: +41 61 228 94 44 Fax: +41 61 228 94 49 christian.ribe...@canoo.com http://www.canoo.com/ On Aug 9, 2009, at 11:10 PM, Niels Mayer wrote: On Fri, Aug 7, 2009 at 11:32 PM, Christian Ribeaud christian.ribe...@canoo.com wrote: Because the mailing list does not seem to accept attached images, here the link to the screenshot: http://www.ribeaud.ch/tmp/xwiki.png I believe this problem can be fixed by hand editing the Objects of type XWiki.XWikiGroups in http://xwiki:8080/xwiki/bin/edit/XWiki/XWikiAllGroup? editor=object then redisplaying http://xwiki:8080/xwiki/bin/view/XWiki/XWikiAllGroup ; in a virtual wiki setup, you may need to do something similar to explicitly set xwiki:XWiki.Admin for each http://vhost:8080/xwiki/ bin/edit/XWiki/XWikiAdminGroup?editor=object prior to calling http://xwiki:8080/xwiki/bin/view/XWiki/XWikiAdminGroup , . This needs some explanation: since you don't necessarily want the local vhost:XWiki.Admin shadowing the root xwiki:XWiki.Admin (the one with programming rights), you don't want the v-host to have a local XWiki.Admin user at all. So if you do this, you'll see additional breakage until the correct root xwiki:XWiki.Admin' user is pointed in the vhost for both XWikiAllGroup and XWikiAdminGroup. If you got these from the latest XAR, you'll probably want to do some hand-editing in a virtual-wiki setup if you hit this issue. Related to the above issue, if you've imported your vhost wiki as the local vhost:XWiki.Admin (which you'd have picked up unless you explicitly excluded in loading the XAR into the v-host), you probably want to re-import the XAR logged in as xwiki:XWiki.Admin (the root user with programming rights set). Otherwise any scripts that expected programming rights in the XAR will silently fail in the virttual-host, even though they work on the root. OpenOffice Server Administration ( http://xwiki:8080/xwiki/bin/admin/XWiki/XWikiPreferences?editor=globaladminsection=XWiki.OfficeImporterAdmin ) is a potential casualty of this kind of installation mistake; so is http://xwiki:8080/xwiki/bin/view/Main/AllDocs?view=attachments (works on root host, shows up empty on any virtual host). The underlying issue is that on a v-host, a document that might need programming rights is only saved as local XWiki.Admin user w/o programming rights; for example http://xwiki:8080/xwiki/bin/edit/Main/AllDocs?editor=wiki and its four included documents -- XWiki.AllAttachments, XWiki.Tableview, XWiki.Treeview, XWiki.OrphanedPages -- are all saved as local XWiki.Admin. However, only http://xwiki:8080/xwiki/bin/view/XWiki/AllAttachments has the problem of displaying empty on a virtual host. I'm assuming that since you're seeing this new users behavior, you're using the recent 2.0M2 release? Here's my initial observations of the same issue you raised posted to the devs list: FYI, http://www.mail-archive.com/d...@xwiki.org/msg09995.html Re: [xwiki-devs] [ANN] XWiki Enterprise 2.0 Milestone 2 released Niels Mayer Mon, 03 Aug 2009 22:21:35 -0700 A few more problems, which i consider more major than previous first impression issues: On the main host of a v-hosted setup: (1) Using administration users panel, add a user. As soon as user is added, no entries in users panel display. Subsequent return to this panel continues to show no users. The added user is created, however, and other user logins still work. However, no subsequent editing or browsing of users in user panel is possible. (2) In administration groups panel, go to a group , e.g. XWikiAdminGroup and add the new user to that group. As soon as this is done, all the users in the group list disappear, yet the lightbox popup remains up. Subsequent
Re: [xwiki-users] XWiki Standalone installation on Vista
Open with notepad the hosts file located at C:\Windows\System32\drivers\etc\hosts You will see a line like this: ::1 localhost So by 'localhost', Windows Vista understands the IPv6 address. Try to add, before that line, this one: 127.0.0.1 localhost If you have the UAC (User Account Control) enabled, you might experience some problems on saving the changes, so try to open notepad with admin rights (In C:\Windows\ right click on notepad.exe and select Run as administrator). After this modification, the http://localhost:8080 should work fine. In Internet Explorer, don't forget to specify the protocol (the http:// part). On Sun, Aug 9, 2009 at 7:44 AM, Meilin Wongmw...@navpower.com wrote: Thanks everyone! I tried all your suggestions and the one that sort-of worked was http://127.0.0.1:8080;. (The other urls just gave the same error page.) The funny thing is that 127.0.0.1 didn't give me the xwiki page, it gave me the page of *another* wiki that I'm simultaneously evaluating (also on port 8080). My bad! No wonder XWiki wasn't running. I uninstalled the other wiki and now the XWiki page comes up just fine. Again, thanks a bunch! - Meilin Andreas Schaefer wrote: When you get http://localhost.com you just forgot to enter http:// this is a nasty behavior of Windows or IE (I am not sure). If everything else fails you can either: edit the hosts file (somwhere in /Windows/System32/..) and add localhost.com 127.0.0.1 or just use 127.0.0.1 instead of localhost. Cheers - Andy On Aug 8, 2009, at 1:01 AM, Sergiu Dumitriu wrote: Meilin Wong wrote: Hi all, I installed XWiki using the standalone install on my Vista64 machine and it looks like the XWiki server starts up fine (using the start_xwiki.bat batch file). However when I try to access http://localhost:8080 with my browser, I keep getting errors as if there is no web server or wiki running at all. I accepted all the defaults when installing except that I installed it under C:\XWiki Enterprise and I ran the installer as administrator. (I'm not sure if I need Java 5. I have Java 6, Update 10.) The error I'm getting in my browser (Firefox 3.0.1) is Page Load Error Network Timeout The server at www.localhost.com is taking too long to respond. Why does it say www.localhost.com? Make sure the address is just http://localhost:8080/, without www or com. The requested site did not respond to a connection request and the browser has stopped waiting for a reply. * Could the server be experiencing high demand or a temporary outage? Try again later. * Are you unable to browse other sites? Check the computer's network connection. * Is your computer or network protected by a firewall or proxy? Incorrect settings can interfere with Web browsing. * Still having trouble? Consult your network administrator or Internet provider for assistance. Has anyone had this kind of error before or have ideas on what I'm missing? Any advice would be greatly appreciated. -- Sergiu Dumitriu http://purl.org/net/sergiu/ ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users -- Teofil Achirei ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] Introducing the equation rendering component and the equation macro
Hello Community,
I have committed today the first implementation of a new XWiki feature:
rendering mathematical equations into images. It is available as a
standalone component, and as a syntax 2.0 macro.
About the functionality.
Equations are written in the TeX/LaTeX syntax, which is pretty simple,
and seems to be the syntax of choice for mathematical equations in other
wikis, too. The macro can distinguish between inline and block equations
and render them accordingly. The output can be either PNG (the default
one), GIF or JPEG. While PNG is definitely the best, I kept the other
two in case somebody really wants to use ancient browsers that only
understand GIF.
Q: Should I leave just PNG as the output format?
Another feature is that the font size can be specified, in order to
render larger or smaller equations. All the font size commands from
LaTeX (from \tiny to \Huge) have an equivalent. I renamed them to a more
easy to understand name (also because the configuration is case
insensitive, so there's no difference between large and LARGE).
By default images are generated so that the font looks relatively OK
with the default XWiki skin on a 72 or 96 DPI display. They might look
disproportionate with a different DPI, or with a different default font
size.
Q: Is the default DPI setting OK?
Second, a few technical details:
The standalone component is located in
platform/core/xwiki-equation-rendering. I don't know if the name is the
best (Vincent complained). On one hand, this describes better what the
component does: it renders equations. On the other hand, it might cause
confusion with the xwiki-rendering system.
The component currently has three implementations:
- a native one, which relies on the latex system being present. It gives
the best results, from a graphical point of view, but requires the
presence of external programs, and involves a slight overhead for
starting new processes and for working with the disk. Currently it might
have some security problems, I'll have to see if opening input and
output files from TeX is a problem, or how to disable this. Any help
from someone who know more about TeX?
Q: Does anybody know of any security issues with running latex, dvips or
convert? Especially with the \openin and \openout commands?
- one which uses MathTran as a remote service through HTTP requests. It
gives results as good as the native one, enhanced with some metadata,
and depending on the configuration of the server, it might have better
performance than the native one. The disadvantage is that it relies
heavily on a remote server. Note that MathTran is free software, and can
be installed locally on the same or a neighboring server. Oh, another
minor problem is that it uses a variant of the TeX syntax, not LaTeX.
- one which uses SnuggleTeX and JEuclid to transform LaTeX into MathML,
and then render it into images. The results are not as eye-pleasing as
those obtained from LaTeX, but it is a self-contained solution, with no
external dependencies.
SnuggleTeX uses the liberal 3-clause BSD license, JEuclid uses the
Apache v2 license, so both can be deployed. Together, they weight in at
730k, so it's not a big impact. The other two implementations are not
contaminated by the licenses of the underlying system, so there's no
license conflict.
Q: Should either one be removed?
Q: Do you know of any other (better) alternative?
By default the native renderer is used, since it gives the best results
and doesn't depend on an external service. SnuggleTeX is configured as a
backup (safe) renderer which kicks in when the default one isn't working
(missing tex subsystem, or communication error with the remote server).
Q: Is this setup OK as the default one? (native by default, snuggletex
as fallback).
The generated images are stored in a cache (using the cache component),
for improved performance. This new cache might increase the memory
requirements, but fortunately it is easy to configure.
The rendering macro is located in
platform/core/xwiki-rendering/xwiki-renderig-macros/xwiki-rendering-macro-equation,
and the macro can be used with
{{equation}}\sum_{i=0}^{\infty}{{/equation}}.
Q: Is the macro name appropriate? Do you know of a better one?
Future work:
- make sure that there are no security issues with the Native backend
- add support for MathML display for the clients that understand it
- improve the alignment of images (especially for the Native backend),
as right now they are a bit raised above the text baseline
Many thanks to Guillaume Legris who provided the starting point for this
component.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Introducing the equation rendering component and the equation macro
Hello Sergiu
I have committed today the first implementation of a new XWiki feature:
rendering mathematical equations into images. It is available as a
standalone component, and as a syntax 2.0 macro.
Nice job, I did not try it as I have no concrete use now, but anyway,
that's a really nice feature as equations are always hard to write for
nice display.
About the functionality.
Equations are written in the TeX/LaTeX syntax, which is pretty simple,
and seems to be the syntax of choice for mathematical equations in other
wikis, too. The macro can distinguish between inline and block equations
and render them accordingly. The output can be either PNG (the default
one), GIF or JPEG. While PNG is definitely the best, I kept the other
two in case somebody really wants to use ancient browsers that only
understand GIF.
Q: Should I leave just PNG as the output format?
I think, at least png and jpg should be kept. Png as default, and jpg as
optional (there are still a lot of jpg fans i guess), for the GIF
format, i don't think it is necessary.
Another feature is that the font size can be specified, in order to
render larger or smaller equations. All the font size commands from
LaTeX (from \tiny to \Huge) have an equivalent. I renamed them to a more
easy to understand name (also because the configuration is case
insensitive, so there's no difference between large and LARGE).
By default images are generated so that the font looks relatively OK
This new cache might increase the memory
requirements, but fortunately it is easy to configure.
The rendering macro is located in
platform/core/xwiki-rendering/xwiki-renderig-macros/xwiki-rendering-macro-equation,
and the macro can be used with
{{equation}}\sum_{i=0}^{\infty}{{/equation}}.
Q: Is the macro name appropriate? Do you know of a better one?
I don't think you can find a better one...
Future work:
- make sure that there are no security issues with the Native backend
- add support for MathML display for the clients that understand it
- improve the alignment of images (especially for the Native backend),
as right now they are a bit raised above the text baseline
Many thanks to Guillaume Legris who provided the starting point for this
component.
Keep up the good work...
And thanks for this nice feature.
Jean
--
Jean Couteau
Code Lutin - http://www.codelutin.com
44 Bd des Pas Enchantés - 44230 St-Sébastien/Loire
Tél : 02 40 50 29 28 - Fax : 09 59 92 29 28
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Introducing the equation rendering component and the equation macro
On Mon, Aug 10, 2009 at 16:14, Sergiu Dumitriuser...@xwiki.com wrote:
Hello Community,
I have committed today the first implementation of a new XWiki feature:
rendering mathematical equations into images. It is available as a
standalone component, and as a syntax 2.0 macro.
About the functionality.
Equations are written in the TeX/LaTeX syntax, which is pretty simple,
and seems to be the syntax of choice for mathematical equations in other
wikis, too. The macro can distinguish between inline and block equations
and render them accordingly. The output can be either PNG (the default
one), GIF or JPEG. While PNG is definitely the best, I kept the other
two in case somebody really wants to use ancient browsers that only
understand GIF.
Q: Should I leave just PNG as the output format?
Another feature is that the font size can be specified, in order to
render larger or smaller equations. All the font size commands from
LaTeX (from \tiny to \Huge) have an equivalent. I renamed them to a more
easy to understand name (also because the configuration is case
insensitive, so there's no difference between large and LARGE).
By default images are generated so that the font looks relatively OK
with the default XWiki skin on a 72 or 96 DPI display. They might look
disproportionate with a different DPI, or with a different default font
size.
Q: Is the default DPI setting OK?
Second, a few technical details:
The standalone component is located in
platform/core/xwiki-equation-rendering. I don't know if the name is the
I don't like this name either rendering is too much linked to the
rendering module now and this could be used by anyone, not only the
equation macro.
It's also true that xwiki-equation is not clear enough but you could
maybe find something else.
best (Vincent complained). On one hand, this describes better what the
component does: it renders equations. On the other hand, it might cause
confusion with the xwiki-rendering system.
The component currently has three implementations:
- a native one, which relies on the latex system being present. It gives
the best results, from a graphical point of view, but requires the
presence of external programs, and involves a slight overhead for
starting new processes and for working with the disk. Currently it might
have some security problems, I'll have to see if opening input and
output files from TeX is a problem, or how to disable this. Any help
from someone who know more about TeX?
Q: Does anybody know of any security issues with running latex, dvips or
convert? Especially with the \openin and \openout commands?
- one which uses MathTran as a remote service through HTTP requests. It
gives results as good as the native one, enhanced with some metadata,
and depending on the configuration of the server, it might have better
performance than the native one. The disadvantage is that it relies
heavily on a remote server. Note that MathTran is free software, and can
be installed locally on the same or a neighboring server. Oh, another
minor problem is that it uses a variant of the TeX syntax, not LaTeX.
- one which uses SnuggleTeX and JEuclid to transform LaTeX into MathML,
and then render it into images. The results are not as eye-pleasing as
those obtained from LaTeX, but it is a self-contained solution, with no
external dependencies.
SnuggleTeX uses the liberal 3-clause BSD license, JEuclid uses the
Apache v2 license, so both can be deployed. Together, they weight in at
730k, so it's not a big impact. The other two implementations are not
contaminated by the licenses of the underlying system, so there's no
license conflict.
Q: Should either one be removed?
Q: Do you know of any other (better) alternative?
By default the native renderer is used, since it gives the best results
and doesn't depend on an external service. SnuggleTeX is configured as a
backup (safe) renderer which kicks in when the default one isn't working
(missing tex subsystem, or communication error with the remote server).
Q: Is this setup OK as the default one? (native by default, snuggletex
as fallback).
The generated images are stored in a cache (using the cache component),
for improved performance. This new cache might increase the memory
requirements, but fortunately it is easy to configure.
The rendering macro is located in
platform/core/xwiki-rendering/xwiki-renderig-macros/xwiki-rendering-macro-equation,
and the macro can be used with
{{equation}}\sum_{i=0}^{\infty}{{/equation}}.
Q: Is the macro name appropriate? Do you know of a better one?
Future work:
- make sure that there are no security issues with the Native backend
- add support for MathML display for the clients that understand it
- improve the alignment of images (especially for the Native backend),
as right now they are a bit raised above the text baseline
Many thanks to Guillaume Legris who provided the starting point for this
Re: [xwiki-users] Introducing the equation rendering component and the equation macro
Hi,
On Mon, Aug 10, 2009 at 4:33 PM, Thomas Mortagne
thomas.morta...@xwiki.comwrote:
On Mon, Aug 10, 2009 at 16:14, Sergiu Dumitriuser...@xwiki.com wrote:
Hello Community,
I have committed today the first implementation of a new XWiki feature:
rendering mathematical equations into images. It is available as a
standalone component, and as a syntax 2.0 macro.
About the functionality.
Equations are written in the TeX/LaTeX syntax, which is pretty simple,
and seems to be the syntax of choice for mathematical equations in other
wikis, too. The macro can distinguish between inline and block equations
and render them accordingly. The output can be either PNG (the default
one), GIF or JPEG. While PNG is definitely the best, I kept the other
two in case somebody really wants to use ancient browsers that only
understand GIF.
Q: Should I leave just PNG as the output format?
I think keeping PNG as the default format is fine too, most browsers accept
it without complaint.
Another feature is that the font size can be specified, in order to
render larger or smaller equations. All the font size commands from
LaTeX (from \tiny to \Huge) have an equivalent. I renamed them to a more
easy to understand name (also because the configuration is case
insensitive, so there's no difference between large and LARGE).
By default images are generated so that the font looks relatively OK
with the default XWiki skin on a 72 or 96 DPI display. They might look
disproportionate with a different DPI, or with a different default font
size.
Q: Is the default DPI setting OK?
Second, a few technical details:
The standalone component is located in
platform/core/xwiki-equation-rendering. I don't know if the name is the
I don't like this name either rendering is too much linked to the
rendering module now and this could be used by anyone, not only the
equation macro.
It's also true that xwiki-equation is not clear enough but you could
maybe find something else.
xwiki-equation-displayer maybe ?
best (Vincent complained). On one hand, this describes better what the
component does: it renders equations. On the other hand, it might cause
confusion with the xwiki-rendering system.
The component currently has three implementations:
- a native one, which relies on the latex system being present. It gives
the best results, from a graphical point of view, but requires the
presence of external programs, and involves a slight overhead for
starting new processes and for working with the disk. Currently it might
have some security problems, I'll have to see if opening input and
output files from TeX is a problem, or how to disable this. Any help
from someone who know more about TeX?
Q: Does anybody know of any security issues with running latex, dvips or
convert? Especially with the \openin and \openout commands?
- one which uses MathTran as a remote service through HTTP requests. It
gives results as good as the native one, enhanced with some metadata,
and depending on the configuration of the server, it might have better
performance than the native one. The disadvantage is that it relies
heavily on a remote server. Note that MathTran is free software, and can
be installed locally on the same or a neighboring server. Oh, another
minor problem is that it uses a variant of the TeX syntax, not LaTeX.
- one which uses SnuggleTeX and JEuclid to transform LaTeX into MathML,
and then render it into images. The results are not as eye-pleasing as
those obtained from LaTeX, but it is a self-contained solution, with no
external dependencies.
SnuggleTeX uses the liberal 3-clause BSD license, JEuclid uses the
Apache v2 license, so both can be deployed. Together, they weight in at
730k, so it's not a big impact. The other two implementations are not
contaminated by the licenses of the underlying system, so there's no
license conflict.
Q: Should either one be removed?
Q: Do you know of any other (better) alternative?
By default the native renderer is used, since it gives the best results
and doesn't depend on an external service. SnuggleTeX is configured as a
backup (safe) renderer which kicks in when the default one isn't working
(missing tex subsystem, or communication error with the remote server).
Q: Is this setup OK as the default one? (native by default, snuggletex
as fallback).
The generated images are stored in a cache (using the cache component),
for improved performance. This new cache might increase the memory
requirements, but fortunately it is easy to configure.
The rendering macro is located in
platform/core/xwiki-rendering/xwiki-renderig-macros/xwiki-rendering-macro-equation,
and the macro can be used with
{{equation}}\sum_{i=0}^{\infty}{{/equation}}.
Q: Is the macro name appropriate? Do you know of a better one?
I think equation is fine.
Re: [xwiki-users] Introducing the equation rendering component and the equation macro
On Mon, Aug 10, 2009 at 9:44 PM, Asiri Rathnayake asiri.rathnay...@gmail.com wrote: Hi, On Mon, Aug 10, 2009 at 8:08 PM, Guillaume Lerouge guilla...@xwiki.comwrote: Hi, On Mon, Aug 10, 2009 at 4:33 PM, Thomas Mortagne thomas.morta...@xwiki.comwrote: On Mon, Aug 10, 2009 at 16:14, Sergiu Dumitriuser...@xwiki.com wrote: Hello Community, I have committed today the first implementation of a new XWiki feature: rendering mathematical equations into images. It is available as a standalone component, and as a syntax 2.0 macro. About the functionality. Equations are written in the TeX/LaTeX syntax, which is pretty simple, and seems to be the syntax of choice for mathematical equations in other wikis, too. The macro can distinguish between inline and block equations and render them accordingly. The output can be either PNG (the default one), GIF or JPEG. While PNG is definitely the best, I kept the other two in case somebody really wants to use ancient browsers that only understand GIF. Q: Should I leave just PNG as the output format? I think keeping PNG as the default format is fine too, most browsers accept it without complaint. Another feature is that the font size can be specified, in order to render larger or smaller equations. All the font size commands from LaTeX (from \tiny to \Huge) have an equivalent. I renamed them to a more easy to understand name (also because the configuration is case insensitive, so there's no difference between large and LARGE). By default images are generated so that the font looks relatively OK with the default XWiki skin on a 72 or 96 DPI display. They might look disproportionate with a different DPI, or with a different default font size. Q: Is the default DPI setting OK? Second, a few technical details: The standalone component is located in platform/core/xwiki-equation-rendering. I don't know if the name is the I don't like this name either rendering is too much linked to the rendering module now and this could be used by anyone, not only the equation macro. It's also true that xwiki-equation is not clear enough but you could maybe find something else. xwiki-equation-displayer maybe ? Few more suggestions: xwiki-equation-plotter, xwiki-formula-plotter, xwiki-formula Another idea: xwiki-plotting |-xwiki-plotting-equation |-xwiki-plotting-graph - Asiri ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Introducing the equation rendering component and the equation macro
On Mon, Aug 10, 2009 at 9:48 PM, Asiri Rathnayake asiri.rathnay...@gmail.com wrote: On Mon, Aug 10, 2009 at 9:44 PM, Asiri Rathnayake asiri.rathnay...@gmail.com wrote: Hi, On Mon, Aug 10, 2009 at 8:08 PM, Guillaume Lerouge guilla...@xwiki.comwrote: Hi, On Mon, Aug 10, 2009 at 4:33 PM, Thomas Mortagne thomas.morta...@xwiki.comwrote: On Mon, Aug 10, 2009 at 16:14, Sergiu Dumitriuser...@xwiki.com wrote: Hello Community, I have committed today the first implementation of a new XWiki feature: rendering mathematical equations into images. It is available as a standalone component, and as a syntax 2.0 macro. About the functionality. Equations are written in the TeX/LaTeX syntax, which is pretty simple, and seems to be the syntax of choice for mathematical equations in other wikis, too. The macro can distinguish between inline and block equations and render them accordingly. The output can be either PNG (the default one), GIF or JPEG. While PNG is definitely the best, I kept the other two in case somebody really wants to use ancient browsers that only understand GIF. Q: Should I leave just PNG as the output format? I think keeping PNG as the default format is fine too, most browsers accept it without complaint. Another feature is that the font size can be specified, in order to render larger or smaller equations. All the font size commands from LaTeX (from \tiny to \Huge) have an equivalent. I renamed them to a more easy to understand name (also because the configuration is case insensitive, so there's no difference between large and LARGE). By default images are generated so that the font looks relatively OK with the default XWiki skin on a 72 or 96 DPI display. They might look disproportionate with a different DPI, or with a different default font size. Q: Is the default DPI setting OK? Second, a few technical details: The standalone component is located in platform/core/xwiki-equation-rendering. I don't know if the name is the I don't like this name either rendering is too much linked to the rendering module now and this could be used by anyone, not only the equation macro. It's also true that xwiki-equation is not clear enough but you could maybe find something else. xwiki-equation-displayer maybe ? Few more suggestions: xwiki-equation-plotter, xwiki-formula-plotter, xwiki-formula Another idea: xwiki-plotting |-xwiki-plotting-equation |-xwiki-plotting-graph Sorry, I meant xwiki-plotting-chart not graph. Anyway, I think both are same :-? - Asiri ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Introducing the equation rendering component and the equation macro
Hi, On Mon, Aug 10, 2009 at 8:08 PM, Guillaume Lerouge guilla...@xwiki.comwrote: Hi, On Mon, Aug 10, 2009 at 4:33 PM, Thomas Mortagne thomas.morta...@xwiki.comwrote: On Mon, Aug 10, 2009 at 16:14, Sergiu Dumitriuser...@xwiki.com wrote: Hello Community, I have committed today the first implementation of a new XWiki feature: rendering mathematical equations into images. It is available as a standalone component, and as a syntax 2.0 macro. About the functionality. Equations are written in the TeX/LaTeX syntax, which is pretty simple, and seems to be the syntax of choice for mathematical equations in other wikis, too. The macro can distinguish between inline and block equations and render them accordingly. The output can be either PNG (the default one), GIF or JPEG. While PNG is definitely the best, I kept the other two in case somebody really wants to use ancient browsers that only understand GIF. Q: Should I leave just PNG as the output format? I think keeping PNG as the default format is fine too, most browsers accept it without complaint. Another feature is that the font size can be specified, in order to render larger or smaller equations. All the font size commands from LaTeX (from \tiny to \Huge) have an equivalent. I renamed them to a more easy to understand name (also because the configuration is case insensitive, so there's no difference between large and LARGE). By default images are generated so that the font looks relatively OK with the default XWiki skin on a 72 or 96 DPI display. They might look disproportionate with a different DPI, or with a different default font size. Q: Is the default DPI setting OK? Second, a few technical details: The standalone component is located in platform/core/xwiki-equation-rendering. I don't know if the name is the I don't like this name either rendering is too much linked to the rendering module now and this could be used by anyone, not only the equation macro. It's also true that xwiki-equation is not clear enough but you could maybe find something else. xwiki-equation-displayer maybe ? Few more suggestions: xwiki-equation-plotter, xwiki-formula-plotter, xwiki-formula - Asiri ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Introducing the equation rendering component and the equation macro
I haven't read the mail yet, I'm just reacting to the name.
Equations means there is an equal sign (see http://en.wikipedia.
org/wiki/Equation).
I'd prefer formula which is more generic.
Thanks
-Vincent
On Aug 10, 2009, at 4:14 PM, Sergiu Dumitriu wrote:
Hello Community,
I have committed today the first implementation of a new XWiki
feature:
rendering mathematical equations into images. It is available as a
standalone component, and as a syntax 2.0 macro.
About the functionality.
Equations are written in the TeX/LaTeX syntax, which is pretty simple,
and seems to be the syntax of choice for mathematical equations in
other
wikis, too. The macro can distinguish between inline and block
equations
and render them accordingly. The output can be either PNG (the default
one), GIF or JPEG. While PNG is definitely the best, I kept the other
two in case somebody really wants to use ancient browsers that only
understand GIF.
Q: Should I leave just PNG as the output format?
Another feature is that the font size can be specified, in order to
render larger or smaller equations. All the font size commands from
LaTeX (from \tiny to \Huge) have an equivalent. I renamed them to a
more
easy to understand name (also because the configuration is case
insensitive, so there's no difference between large and LARGE).
By default images are generated so that the font looks relatively OK
with the default XWiki skin on a 72 or 96 DPI display. They might look
disproportionate with a different DPI, or with a different default
font
size.
Q: Is the default DPI setting OK?
Second, a few technical details:
The standalone component is located in
platform/core/xwiki-equation-rendering. I don't know if the name is
the
best (Vincent complained). On one hand, this describes better what the
component does: it renders equations. On the other hand, it might
cause
confusion with the xwiki-rendering system.
The component currently has three implementations:
- a native one, which relies on the latex system being present. It
gives
the best results, from a graphical point of view, but requires the
presence of external programs, and involves a slight overhead for
starting new processes and for working with the disk. Currently it
might
have some security problems, I'll have to see if opening input and
output files from TeX is a problem, or how to disable this. Any help
from someone who know more about TeX?
Q: Does anybody know of any security issues with running latex,
dvips or
convert? Especially with the \openin and \openout commands?
- one which uses MathTran as a remote service through HTTP requests.
It
gives results as good as the native one, enhanced with some metadata,
and depending on the configuration of the server, it might have better
performance than the native one. The disadvantage is that it relies
heavily on a remote server. Note that MathTran is free software, and
can
be installed locally on the same or a neighboring server. Oh, another
minor problem is that it uses a variant of the TeX syntax, not LaTeX.
- one which uses SnuggleTeX and JEuclid to transform LaTeX into
MathML,
and then render it into images. The results are not as eye-pleasing as
those obtained from LaTeX, but it is a self-contained solution, with
no
external dependencies.
SnuggleTeX uses the liberal 3-clause BSD license, JEuclid uses the
Apache v2 license, so both can be deployed. Together, they weight in
at
730k, so it's not a big impact. The other two implementations are not
contaminated by the licenses of the underlying system, so there's no
license conflict.
Q: Should either one be removed?
Q: Do you know of any other (better) alternative?
By default the native renderer is used, since it gives the best
results
and doesn't depend on an external service. SnuggleTeX is configured
as a
backup (safe) renderer which kicks in when the default one isn't
working
(missing tex subsystem, or communication error with the remote
server).
Q: Is this setup OK as the default one? (native by default, snuggletex
as fallback).
The generated images are stored in a cache (using the cache
component),
for improved performance. This new cache might increase the memory
requirements, but fortunately it is easy to configure.
The rendering macro is located in
platform/core/xwiki-rendering/xwiki-renderig-macros/xwiki-rendering-
macro-equation,
and the macro can be used with
{{equation}}\sum_{i=0}^{\infty}{{/equation}}.
Q: Is the macro name appropriate? Do you know of a better one?
Future work:
- make sure that there are no security issues with the Native backend
- add support for MathML display for the clients that understand it
- improve the alignment of images (especially for the Native backend),
as right now they are a bit raised above the text baseline
Many thanks to Guillaume Legris who provided the starting point for
Re: [xwiki-users] Introducing the equation rendering component and the equation macro
Sergiu Dumitriu wrote:
Hello Community,
I have committed today the first implementation of a new XWiki feature:
rendering mathematical equations into images. It is available as a
standalone component, and as a syntax 2.0 macro.
About the functionality.
Equations are written in the TeX/LaTeX syntax, which is pretty simple,
and seems to be the syntax of choice for mathematical equations in other
wikis, too. The macro can distinguish between inline and block equations
and render them accordingly. The output can be either PNG (the default
one), GIF or JPEG. While PNG is definitely the best, I kept the other
two in case somebody really wants to use ancient browsers that only
understand GIF.
Q: Should I leave just PNG as the output format?
I would like the PNG output as default, but also keep the GIF and JPEG
since there are some problems with PNG images on ancient IE6.
Oana
Another feature is that the font size can be specified, in order to
render larger or smaller equations. All the font size commands from
LaTeX (from \tiny to \Huge) have an equivalent. I renamed them to a more
easy to understand name (also because the configuration is case
insensitive, so there's no difference between large and LARGE).
By default images are generated so that the font looks relatively OK
with the default XWiki skin on a 72 or 96 DPI display. They might look
disproportionate with a different DPI, or with a different default font
size.
Q: Is the default DPI setting OK?
Second, a few technical details:
The standalone component is located in
platform/core/xwiki-equation-rendering. I don't know if the name is the
best (Vincent complained). On one hand, this describes better what the
component does: it renders equations. On the other hand, it might cause
confusion with the xwiki-rendering system.
The component currently has three implementations:
- a native one, which relies on the latex system being present. It gives
the best results, from a graphical point of view, but requires the
presence of external programs, and involves a slight overhead for
starting new processes and for working with the disk. Currently it might
have some security problems, I'll have to see if opening input and
output files from TeX is a problem, or how to disable this. Any help
from someone who know more about TeX?
Q: Does anybody know of any security issues with running latex, dvips or
convert? Especially with the \openin and \openout commands?
- one which uses MathTran as a remote service through HTTP requests. It
gives results as good as the native one, enhanced with some metadata,
and depending on the configuration of the server, it might have better
performance than the native one. The disadvantage is that it relies
heavily on a remote server. Note that MathTran is free software, and can
be installed locally on the same or a neighboring server. Oh, another
minor problem is that it uses a variant of the TeX syntax, not LaTeX.
- one which uses SnuggleTeX and JEuclid to transform LaTeX into MathML,
and then render it into images. The results are not as eye-pleasing as
those obtained from LaTeX, but it is a self-contained solution, with no
external dependencies.
SnuggleTeX uses the liberal 3-clause BSD license, JEuclid uses the
Apache v2 license, so both can be deployed. Together, they weight in at
730k, so it's not a big impact. The other two implementations are not
contaminated by the licenses of the underlying system, so there's no
license conflict.
Q: Should either one be removed?
Q: Do you know of any other (better) alternative?
By default the native renderer is used, since it gives the best results
and doesn't depend on an external service. SnuggleTeX is configured as a
backup (safe) renderer which kicks in when the default one isn't working
(missing tex subsystem, or communication error with the remote server).
Q: Is this setup OK as the default one? (native by default, snuggletex
as fallback).
The generated images are stored in a cache (using the cache component),
for improved performance. This new cache might increase the memory
requirements, but fortunately it is easy to configure.
The rendering macro is located in
platform/core/xwiki-rendering/xwiki-renderig-macros/xwiki-rendering-macro-equation,
and the macro can be used with
{{equation}}\sum_{i=0}^{\infty}{{/equation}}.
Q: Is the macro name appropriate? Do you know of a better one?
Future work:
- make sure that there are no security issues with the Native backend
- add support for MathML display for the clients that understand it
- improve the alignment of images (especially for the Native backend),
as right now they are a bit raised above the text baseline
Many thanks to Guillaume Legris who provided the starting point for this
component.
___
users mailing list
users@xwiki.org
Re: [xwiki-users] Users not displayed
many thanks for your answer. However I am not sure I understood everything. What I actually would like to know is what should I do to solve this critical problem? How should I edit the http://xwiki:8080/xwiki/bin/edit/XWiki/XWikiAllGroup?editor=object for instance? First, browse /xwiki/bin/view/XWiki/XWikiAllGroup if this doesn't have all the registered users of your wiki listed, then they will not have privilege to do much of anything on the wiki. This can happen, for example, if you overwrite your original XWikiAllGroup file with the one from the XAR at import-time. If that happens, or if XWikiAdminGroup is similarly overwritten or damaged, then additional administrators won't be granted that privilege. Hand editing of the objects associated with these documents may be necessary if the above happens,. Hand editing is also necessitated by the new bug that occurs from add user or add member to group causing /xwiki/bin/view/XWiki/XWikiAllGroup and /xwiki/bin/view/XWiki/XWikiAdminGroup to not list the associated users. I guess this must be a regression introduced into 1.9 as 1.8 didn't have this problem, and also had a different implementation and appearance for viewing XWikiAllGroup and XWikiAdminGroup. To hand-edit these documents, as 'Admin', select document menu Edit-Object. In the object editor, note that each object is displayed in an accordion with each object heading looking like XWiki.XWikiGroups[11] (1.8) or Objects of type XWiki.XWikiGroups...XWikiGroups 6: XWiki.NielsMayer (2.0). Fully expand the accordions to see the contents of the objects you want to verify and edit. On each of these group-documents (e.g. XWiki.XWikiAdminGroup, XWiki.XWikiAllGroup), there are multiple object instances of XWiki.XWikiGroups, each having a single Member field; that field contains a single valid XWiki user. Verify that the document referenced as the user, e.g. XWiki.NielsMayer exists and has appropriate rights for each user listed as Member. Delete any XWiki.XWikiGroups instances that don't correspond to a real user on your wiki; use the Add Object panel on the right to add new instances of XWiki.XWikiGroups to the group docs for any users not listed. (You don't need to delete an invalid member and separately add a valid one, just change the invalid document in the member field to a valid one). Finally, go to Administration-Rights and make sure the group documents you just hand edited have appropriate rights, e.g. Wiki.XWikiAdminGroup should probably have Edit Delete and Admin checked; XWiki.XWikiAllGroup should probably have View and Comment selected. This might be needed if you overwrote XWiki.XWikiPreferences in importing the new XAR. On the other hand, sometimes you might need to overwrite XWiki.XWikiPreferences (e.g. in upgrading Xwiki across big revision changes). It's probably a good idea to allow XWiki.XWikiPreferences to get overwritten across big Xwiki revision changes, just re-do Administration- General, Presentation, Registration, Programming and Rights*.* One helpful tip is to use your browser's form-field autocompletion features to save the contents of the fields of the old wiki by re-saving General, Presentation, Registration, Programming and Rights prior to upgrading the wiki. After upgrading, use your browser's memory of prior form fileds to reinsert the appropriate prior form-field contents back into the form, and re-save. * *It would be a nice addition to XWiki to have some kind of merging tool on import. This would allow updating of system documents with new features or bugfixes, while giving the wiki administrator bettter control over customizations made in the wiki. Something like http://n2.nabble.com/import-administration-enhancement-feature-request-td2488744.html * ... ***Niels http://nielsmayer.com ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] upgrading wiki farm?
On Fri, Aug 7, 2009 at 21:46, Kelly Lakaskla...@nwlinc.com wrote: Hi - I have XEM 1.7.1/XE 2.0 milestone 1. I see that the Main.AllDocs issue is resolved with XE 2.0 milestone 2. Do I need to upgrade to XE 2.0 milestone 2 and then convert again to XEM 1.7.2, or can I just install XEM 1.7.2 war and that will fix the issue? Also, if I do upgrade to xe and then convert again, will I lose all the virtual wiki's I've created? XEM 1.7.2 is based in XE 1.9.2 not 2.0M2. XE 2.0 based XEM release will only starts when 2.0 is stable. See http://www.xwiki.org/xwiki/bin/view/Main/Download#HXWikiEnterpriseManager No, upgrading XE does not remove any data, it's doing what you ask it to do. XEM is just XE+applications+configuration, when you upgrade XE it just upgrade XE it will not touch XEM specific pages so no you don't need to convert again to XEM. Just make sure you keep the same configuration in xwiki.cfg, specifically xwiki.virtual=1 but anyway when you upgrade a wiki you are supposed to check all the configuration. See http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Installation#HUpgradinganXWikiInstallation Also note that since each wiki has its own database and pages you have to upgrade each wiki you want to upgrade with the xar file. Any help would be great, thanks. Kelly Kelly Lakas Project Manager next wave logistics inc. 28377 davis parkway, suite 607a warrenville, il 60555 [office] 847.798.8897 [mobile] 312.307.2079 [web] www.nwlinc.com http://www.nwlinc.com ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users -- Thomas Mortagne ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] Xwiki 1.8 WAR file?
Is there any way that I could download the Xwiki WAR file of version 1.8? I had a server crash and my database backup didn't work. I was able to export all of the pages in my wiki as .xar files, but when I try to import some of them, I get messages that say there are no documents in the .xar files. I think this is because my new installation is 2.0, instead of 1.8. I tried 1.9, and it helped a little. I could import a few more of the pages, but there are still a couple that I cannot. I would try to use the files from the server, but it is officially toast now. Any help would be greatly appreciated. Thanks, travis ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Xwiki 1.8 WAR file?
Hi Travis, See http://forge.objectweb.org/project/showfiles.php?group_id=170 (linked from http://www.xwiki.org/xwiki/bin/view/Main/Download) Thanks -Vincent On Aug 10, 2009, at 10:58 PM, Travis Riggs wrote: Is there any way that I could download the Xwiki WAR file of version 1.8? I had a server crash and my database backup didn't work. I was able to export all of the pages in my wiki as .xar files, but when I try to import some of them, I get messages that say there are no documents in the .xar files. I think this is because my new installation is 2.0, instead of 1.8. I tried 1.9, and it helped a little. I could import a few more of the pages, but there are still a couple that I cannot. I would try to use the files from the server, but it is officially toast now. Any help would be greatly appreciated. Thanks, travis ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Xwiki 1.8 WAR file?
Travis Riggs wrote: Is there any way that I could download the Xwiki WAR file of version 1.8? I had a server crash and my database backup didn't work. I was able to export all of the pages in my wiki as .xar files, but when I try to import some of them, I get messages that say there are no documents in the .xar files. I think this is because my new installation is 2.0, instead of 1.8. I tried 1.9, and it helped a little. I could import a few more of the pages, but there are still a couple that I cannot. I would try to use the files from the server, but it is officially toast now. Any help would be greatly appreciated. Usually the XWiki version should not matter for imports. The XAR format is a pretty stable one, so there's nothing that would prevent a 2.0 wiki from importing a 1.8 XAR. -- Sergiu Dumitriu http://purl.org/net/sergiu/ ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
