Re: [xwiki-users] Horizontal menu like xwiki.org
For my version you need to make changes in the Skin.
When you download the xar you have a XWikiOrgCode.Skin page. You should set
this page as your active skin in Administration - Presentation - Skin or
add to your skin in the header section these lines:
#template('global.vm')
$xwiki.includeForm('xwiki:XWikiOrgCode.MenuMacro',false)
Hope this helps,
Caty
On Thu, Jul 26, 2012 at 4:51 PM, eisioriginal
aniek...@informatik.uni-leipzig.de wrote:
Hello,
i also used the branch of the menu and tried to include it. I altered the
code for the Menu Panel Extension:
{{velocity}}
##$xwiki.ssx.use('xwiki:XWikiOrgCode.MenuMacro')
##{{menu id=navigationMenu}}
{{menu type=horizontal position=left id=mainMenu}}
#set($menuContentProperty =
$xwiki.getDocument(MenuCode.MenuConfig).getObject(MenuCode.MenuConfig).getProperty('content').value)
#if($!menuContentProperty == '' or $!menuContentProperty == \\)
* [[Edit the menu in
administrationXWiki.XWikiPreferences?editor=globaladminsection=MenuConfig]]
#else
$menuContentProperty
#end
{{/menu}}
{{/velocity}}
This leads to the behavior that the menu is rendered in the panel and not
on
top of the page. Can you give me a hint how to include the xwiki menu to
the
top of the page. I'm new to xwiki and i do not know if i can set the menu
globally for all spaces.
All the best
Andreas
--
View this message in context:
http://xwiki.475771.n2.nabble.com/Horizontal-menu-like-xwiki-org-tp7411641p7580563.html
Sent from the XWiki- Users mailing list archive at Nabble.com.
___
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
[xwiki-users] Error using Code Macro
Hello,
We're using the Code Macro estension (
http://extensions.xwiki.org/xwiki/bin/view/Extension/Code+Macro ). We are
using it like this:
{{code language=java}}
our code
{{/code}}
And then this error appears:
org.xwiki.rendering.macro.MacroExecutionException: Failed to highlight
content
at
org.xwiki.rendering.internal.macro.code.CodeMacro.parseContent(CodeMacro.java:108)
at
org.xwiki.rendering.internal.macro.code.CodeMacro.parseContent(CodeMacro.java:48)
at
org.xwiki.rendering.macro.box.AbstractBoxMacro.execute(AbstractBoxMacro.java:146)
at
org.xwiki.rendering.macro.box.AbstractBoxMacro.execute(AbstractBoxMacro.java:51)
at
org.xwiki.rendering.internal.transformation.macro.MacroTransformation.transformOnce(MacroTransformation.java:184)
at
org.xwiki.rendering.internal.transformation.macro.MacroTransformation.transform(MacroTransformation.java:129)
at
org.xwiki.rendering.internal.transformation.DefaultTransformationManager.performTransformations(DefaultTransformationManager.java:72)
at
com.xpn.xwiki.doc.XWikiDocument.performSyntaxConversion(XWikiDocument.java:7605)
at
com.xpn.xwiki.doc.XWikiDocument.performSyntaxConversion(XWikiDocument.java:7554)
at
com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:836)
at
com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:785)
at
com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:879)
...
Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to
lookup component [role = [org.xwiki.rendering.parser.HighlightParser] hint
= [default]]
at
org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:368)
at
org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:126)
at
org.xwiki.component.internal.DefaultComponentManager.lookup(DefaultComponentManager.java:85)
at
org.xwiki.rendering.internal.macro.code.CodeMacro.highlight(CodeMacro.java:144)
at
org.xwiki.rendering.internal.macro.code.CodeMacro.parseContent(CodeMacro.java:105)
... 104 more
Caused by: Traceback (most recent call last):
File string, line 1, in module
File __pyclasspath__/pygments/__init__.py, line 37, in module
File __pyclasspath__/pygments/util.py, line 12, in module
ImportError: No module named re
at
org.python.core.PyException.fillInStackTrace(PyException.java:70)
at java.lang.Throwable.init(Throwable.java:56)
at org.python.core.PyException.init(PyException.java:46)
at org.python.core.PyException.init(PyException.java:43)
at org.python.core.PyException.init(PyException.java:61)
at org.python.core.Py.ImportError(Py.java:290)
..
We thought that the code we added may be wrong, but if we just write {{code
language=java}}{{/code}} , we get the same error.
Any clue of what's causing this error?
Thanks in Advance
Sergio Carrasco
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Error using Code Macro
On Mon, Jul 30, 2012 at 2:42 PM, Sergio Carrasco sercar...@gmail.com wrote:
Hello,
We're using the Code Macro estension (
http://extensions.xwiki.org/xwiki/bin/view/Extension/Code+Macro ). We are
using it like this:
{{code language=java}}
our code
{{/code}}
And then this error appears:
org.xwiki.rendering.macro.MacroExecutionException: Failed to highlight
content
at
org.xwiki.rendering.internal.macro.code.CodeMacro.parseContent(CodeMacro.java:108)
at
org.xwiki.rendering.internal.macro.code.CodeMacro.parseContent(CodeMacro.java:48)
at
org.xwiki.rendering.macro.box.AbstractBoxMacro.execute(AbstractBoxMacro.java:146)
at
org.xwiki.rendering.macro.box.AbstractBoxMacro.execute(AbstractBoxMacro.java:51)
at
org.xwiki.rendering.internal.transformation.macro.MacroTransformation.transformOnce(MacroTransformation.java:184)
at
org.xwiki.rendering.internal.transformation.macro.MacroTransformation.transform(MacroTransformation.java:129)
at
org.xwiki.rendering.internal.transformation.DefaultTransformationManager.performTransformations(DefaultTransformationManager.java:72)
at
com.xpn.xwiki.doc.XWikiDocument.performSyntaxConversion(XWikiDocument.java:7605)
at
com.xpn.xwiki.doc.XWikiDocument.performSyntaxConversion(XWikiDocument.java:7554)
at
com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:836)
at
com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:785)
at
com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:879)
...
Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to
lookup component [role = [org.xwiki.rendering.parser.HighlightParser] hint
= [default]]
at
org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:368)
at
org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:126)
at
org.xwiki.component.internal.DefaultComponentManager.lookup(DefaultComponentManager.java:85)
at
org.xwiki.rendering.internal.macro.code.CodeMacro.highlight(CodeMacro.java:144)
at
org.xwiki.rendering.internal.macro.code.CodeMacro.parseContent(CodeMacro.java:105)
... 104 more
Caused by: Traceback (most recent call last):
File string, line 1, in module
File __pyclasspath__/pygments/__init__.py, line 37, in module
File __pyclasspath__/pygments/util.py, line 12, in module
ImportError: No module named re
at
org.python.core.PyException.fillInStackTrace(PyException.java:70)
at java.lang.Throwable.init(Throwable.java:56)
at org.python.core.PyException.init(PyException.java:46)
at org.python.core.PyException.init(PyException.java:43)
at org.python.core.PyException.init(PyException.java:61)
at org.python.core.Py.ImportError(Py.java:290)
..
We thought that the code we added may be wrong, but if we just write {{code
language=java}}{{/code}} , we get the same error.
According to the error you have the issue does not really comes from
code macro but from Jython. Looks like for some reason XWiki can't
find standard Jython libraries which are used in Pygments
(highlighting Python library used by code macro).
If you use JBoss application server you probably hit
http://jira.xwiki.org/browse/XWIKI-7984 and if it's another one it's
probably still the same kind of issues (would be nice to crate another
issue in that case). There is a workaround you can try in the jira
issue description.
Any clue of what's causing this error?
Thanks in Advance
Sergio Carrasco
___
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
Re: [xwiki-users] Regular users can edit access rights?
Hi Moritz, On Thu, Jul 12, 2012 at 8:46 AM, Moritz Hesse (EnergieArchitektur) moritz.he...@ea-gmbh.de wrote: Hi, we have made the experience, that regular users can edit access rights for pages. Is this regular behaviour? Yes. Right now, given that an user with edit rights can add objects to a page, that user is able to add XWikiRights objects and thus set rights at the page level. And funnily: The user can only _grant_ access rights but cannot revoke them. Plus: he can only grant it to _one_ group/user. In both cases (when trying to revoke or when trying to grant to any other group/user) the system says, that there was an error when communicating with the server. I think there is some kind of safety code related to this, but you'd need a developer to verify. It might simply be a bug. Is it in gerenal possible to restrict access to the access page and to the objects page for regular users? You could look at changing the Apache configuration to disallow adding XWikiRights objects, or write a listener in XWiki that detects these kind of changes and rolls them back automatically if the context user is not an admin. Thanks, Guillaume Thanks! ___ 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
Re: [xwiki-users] wysywig: link creating dialog
On Tue, Jul 24, 2012 at 1:15 PM, Arioch arioch...@gmail.com wrote: on 1st page of it, the only button right bottom corner, is it to be Select as in Choose, rather than Select as in pick ? I don't really see the difference between choose and pick in this context. The meaning is Use the selected page as the target of the link. Hope this helps, Marius Guess russian l18n is wrong there -- View this message in context: http://xwiki.475771.n2.nabble.com/wysywig-link-creating-dialog-tp7580485.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ 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
Re: [xwiki-users] Special character '#' in title
Sorry for the late reply.
On Fri, Jul 20, 2012 at 12:46 PM, CHENEAU-GREHALLE Nicolas
nicolas.cheneau-greha...@sesam-vitale.fr wrote:
Hi,
We have a problem with titles with the 4.1.3 release (not sure if it's
release specific however, I just spend lot of time in logs because of
the migration) :
When title contains the character '#' at the end, the title disappears
from the page (only the page name is printed). There is error traces
when viewing the document and from Lucene :
2012/07/19 14:35:34
[http://localhost:8080/xem/wiki/supporttechnique/get/XWiki/SuggestLucene
Service?outputSyntax=plainquery=__INPUT__*nb=3input=8192] WARN
o.x.d.i.DocumentTitleDisplayer - Failed to interpret title of document
[supporttechnique:Archives.ExempleCodeC].
2012/07/20 10:06:22
[http://localhost:8080/xem/wiki/supporttechnique/get/Archives/ExempleCod
eC?xpage=xpartvm=commentsinline.vm] WARN
o.x.d.i.DocumentTitleDisplayer - Failed to interpret title of document
[supporttechnique:Archives.ExempleCodeC].
Is it a known bug ?
It's not a bug, it's a feature. XWiki supports Velocity code (
http://velocity.apache.org/engine/releases/velocity-1.7/user-guide.html
) in page title and # is a special Velocity character that precedes
Velocity statements, macro definitions and calls. You can reproduce
the problem by putting:
{{velocity}}
test#
{{/velocity}}
in the content of a wiki page. The solution is to escape the hash
character using
http://velocity.apache.org/tools/devel/generic/EscapeTool.html#getHash%28%29
:
Your title$escapetool.h
Hope this helps,
Marius
Thank you
Nicolas
___
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
Re: [xwiki-users] Diff font is
On Thu, Jul 19, 2012 at 12:20 PM, Arioch arioch...@gmail.com wrote:
That only displays so in MSIE9, not in Opera 12.
However CSS inspection in MSIE is not not comfort.
Okay.
Trigger is : div.diff-container {font-family }
If i remove courier from there or put it after monospace - then MSIE
renders more or less okay.
I'd like to note:
1) u use inherit values even on root element - HTML/BODY does it have sense
there ?
It's called CSS Reset, and it's a technique used all over the web.
2) dunno about Chrome and Moz, but in Opera and MSIe use of inherit strikes
out all other values. IT is hard to track which value is in effect :-/ Had
to remove styles one after another.
3) inherit only supported since MSIE 8. You render out MSIE6 and MSIE 7.
IE6 and 7 are not supported any more.
Would have to try tpo push for MSIE8 upgrade if install xwiki into intranet.
4) Both MSIE9 Devtools and Opera DragonFly shoes monospace without qoutes
and Courier in quotes, regardless of case. So to me it suggests that
monospace is standard CSS value and Courier/courier is not, probably
meaning some proprietary font *name* and then browsers think how to override
it (non standard vendor-specific behaviour). To support this idea:
As per http://www.w3.org/TR/CSS21/fonts.html#algorithm the browser
should first try Courier and if it doesn't support it then it should
fall back on Monospace which is next on the font-family list. The fact
that IE9 stops at Courier font means that it is supported. The fact
that the text is badly displayed is IMO a IE9 bug.
4.0) as i remember, Courier was old raster 16-bit Windows font. Scaleable
TTf font is called Courier New
4.1) If i set the value courier new, monospace that looks in MSIE9 exactly
like monospace alone.
Probably because IE9 doesn't support courier new.
I guess the fix is in your case to just remove the Courier font from
the value of the font-family CSS property.
Hope this helps,
Marius
4.2) in Opera courier new is getting quotations exactly like courier
4.3) all CSS tutorials i googled enumerate 5 standard values and Courier is
not among them.
http://www.w3schools.com/cssref/pr_font_font-family.asp
http://en.wikipedia.org/wiki/Font_family_(HTML)#Generic_font_families
4.4) Opera always had flexible font re-mapping, 10 years ago it was very
needed without encodings support.
http://help.opera.com/Linux/9.52/en/fonts.html
The screenshots are http://imgur.com/a/UE4h5 - i feel they support this
idea.
The comparision of liens at http://imgur.com/a/55Xrq also suggests it.
4.5) i asked a question would see
http://dev.opera.com/articles/view/fonts-for-web-design-a-primer/#comments
Same effect i see on http://www.indeep76.com/Style/Example007/fonts.html
Funny thing, on http://y3x.ru/sandbox/css/font-family/ it is the opposite
picture. MSIE works with Courier+monospace nicely and Opera fails.
--
View this message in context:
http://xwiki.475771.n2.nabble.com/Diff-font-is-tp7580425p7580437.html
Sent from the XWiki- Users mailing list archive at Nabble.com.
___
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
Re: [xwiki-users] Diff font is
On 07/30/2012 11:13 AM, Marius Dumitru Florea wrote:
On Thu, Jul 19, 2012 at 12:20 PM, Arioch arioch...@gmail.com wrote:
That only displays so in MSIE9, not in Opera 12.
However CSS inspection in MSIE is not not comfort.
Okay.
Trigger is : div.diff-container {font-family }
If i remove courier from there or put it after monospace - then MSIE
renders more or less okay.
I'd like to note:
1) u use inherit values even on root element - HTML/BODY does it have sense
there ?
It's called CSS Reset, and it's a technique used all over the web.
2) dunno about Chrome and Moz, but in Opera and MSIe use of inherit strikes
out all other values. IT is hard to track which value is in effect :-/ Had
to remove styles one after another.
3) inherit only supported since MSIE 8. You render out MSIE6 and MSIE 7.
IE6 and 7 are not supported any more.
Would have to try tpo push for MSIE8 upgrade if install xwiki into intranet.
4) Both MSIE9 Devtools and Opera DragonFly shoes monospace without qoutes
and Courier in quotes, regardless of case. So to me it suggests that
monospace is standard CSS value and Courier/courier is not, probably
meaning some proprietary font *name* and then browsers think how to override
it (non standard vendor-specific behaviour). To support this idea:
As per http://www.w3.org/TR/CSS21/fonts.html#algorithm the browser
should first try Courier and if it doesn't support it then it should
fall back on Monospace which is next on the font-family list. The fact
that IE9 stops at Courier font means that it is supported. The fact
that the text is badly displayed is IMO a IE9 bug.
4.0) as i remember, Courier was old raster 16-bit Windows font. Scaleable
TTf font is called Courier New
4.1) If i set the value courier new, monospace that looks in MSIE9 exactly
like monospace alone.
Probably because IE9 doesn't support courier new.
Font names with spaces in them should be placed in quotes. Try:
font-family: Courier New, monospace;
I guess the fix is in your case to just remove the Courier font from
the value of the font-family CSS property.
Hope this helps,
Marius
4.2) in Opera courier new is getting quotations exactly like courier
4.3) all CSS tutorials i googled enumerate 5 standard values and Courier is
not among them.
http://www.w3schools.com/cssref/pr_font_font-family.asp
http://en.wikipedia.org/wiki/Font_family_(HTML)#Generic_font_families
4.4) Opera always had flexible font re-mapping, 10 years ago it was very
needed without encodings support.
http://help.opera.com/Linux/9.52/en/fonts.html
The screenshots are http://imgur.com/a/UE4h5 - i feel they support this
idea.
The comparision of liens at http://imgur.com/a/55Xrq also suggests it.
4.5) i asked a question would see
http://dev.opera.com/articles/view/fonts-for-web-design-a-primer/#comments
Same effect i see on http://www.indeep76.com/Style/Example007/fonts.html
Funny thing, on http://y3x.ru/sandbox/css/font-family/ it is the opposite
picture. MSIE works with Courier+monospace nicely and Opera fails.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] sources filename, why that redundancy ?
On Thu, Jul 19, 2012 at 10:48 AM, Arioch arioch...@gmail.com wrote: I am not XWiki developer and hardly ever would be. Even if i have my favorite mysfeatures. Also here are script-making and script-using guys. So i don't think this question would be complete off-topic. === It seems that XWiki was never tested on Windows as none of developers had it. It seems that XWiki GitHub just cannot be cloned to Windows now. And i don't know if can be compiled there (hopefully JVM can overcome it, but who knows) But what i noticed again, is that hugely redundant file naming xwiki-platform-core/xwiki-platform-classloader/xwiki-platfor m-classloader-protocols/xwiki-platform-classloader-protocol-attachmentjar/src/te st/java/org/xwiki/classloader/internal/protocol/attachmentjar/AttachmentURLStrea mHandlerTest.java Why that repeating time and gain, like if you use flat filesystem rather than tree ? It's a naming convention we agreed on: the maven module folder name should be the same as the maven module artifact ID. Thanks, Marius It looks like calling an object org.org-xwiki.org-xwiki-classloader.org-xwiki-classloader-internal.org-xwiki-classloader-internal-protocol.org-xwiki-classloader-internal-protocol-attachmentjar.org-xwiki-classloader-internal-protocol-attachmentjar-AttachmentURLStreamHandlerTest Nonsense ? Truly so. Yet on file system level Java developers usually do it, not only XWiki but many teams. Why ? Aren't directories given to suppress such redundancy ? Not only that give overly long unobservable paths, it also disables some programs on Windows. I heard that git has internal 4KB file path length limitations. I wonder what UNIX guys would say about sanity if one day they would try to download from Windows file with name about 16KB long... -- View this message in context: http://xwiki.475771.n2.nabble.com/sources-filename-why-that-redundancy-tp7580435.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ 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
Re: [xwiki-users] sources filename, why that redundancy ?
Marius Dumitru Florea [via XWiki] ml-node+s475771n7580616...@n2.nabble.com писал(а) в своём письме Mon, 30 Jul 2012 19:29:34 +0400: But what i noticed again, is that hugely redundant file naming xwiki-platform-core/xwiki-platform-classloader/xwiki-platfor m-classloader-protocols/xwiki-platform-classloader-protocol-attachmentjar/src/te st/java/org/xwiki/classloader/internal/protocol/attachmentjar/AttachmentURLStrea mHandlerTest.javaWhy that repeating time and gain, like if you use flat filesystem ratherthan tree ? It's a naming convention we agreed on: the maven module folder name should be the same as the maven module artifact ID. Well, if u chosen to keep all the genealogy in the folder name, modellign after flat 1D maven list, then folder structure can be kept flat too. Call it Windows limitations or Git/Win lack of intelligency, yet you casted aside all potential Windows-based developers. -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ -- View this message in context: http://xwiki.475771.n2.nabble.com/sources-filename-why-that-redundancy-tp7580435p7580618.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Diff font is
Marius Dumitru Florea [via XWiki] ml-node+s475771n7580614...@n2.nabble.com писал(а) в своём письме Mon, 30 Jul 2012 19:13:51 +0400: 1) u use inherit values even on root element - HTML/BODY does it have sensethere ? It's called CSS Reset, and it's a technique used all over the web. I googled for term and found http://sixrevisions.com/css/css-tips/css-tip-1-resetting-your-styles-with-css-reset/ This concept is opposite to inheritance, it is massive overriding of inherited values rather than re-using them. It also sits in th basement, between browser built-in defaults and real styles. While inherit value seems to be be all through CSS from mos basic to most narrow selectors. 4) Both MSIE9 Devtools and Opera DragonFly shoes monospace without qoutesand Courier in quotes, regardless of case. So to me it suggests thatmonospace is standard CSS value and Courier/courier is not, probablymeaning some proprietary font *name* and then browsers think how to overrideit (non standard vendor-specific behaviour). To support this idea: As per http://www.w3.org/TR/CSS21/fonts.html#algorithm the browsershould first try Courier and if it doesn't support it then it shouldfall back on Monospace which is next on the font-family list. The factthat IE9 stops at Courier font means that it is supported. The factthat the text is badly displayed is IMO a IE9 bug. No, it is not a bug. It is exactly what Courier font is. Raster font obsoleted back in 1992. In today world of vector fonts, bitmap files that were not updated since 1992 might be pardoned for looking less than fancy. 4.1) If i set the value courier new, monospace that looks in MSIE9 exactlylike monospace alone. Probably because IE9 doesn't support courier new. How can it not support the font foudn in system, while supporting all other fonts ? I already given an explanation - MSIE sets Courier New as a default font for monospace alias. So if you select that name by font or by alias does not make difference. That's how Opera would react on Consolas, monospace, for it sets Consolas for default value to monospace alias. I guess the fix is in your case to just remove the Courier font fromthe value of the font-family CSS property. I guess font's name-calling is just to be removed from CSS. That was sub-standard legacy-compatibility measure when there was no support for CSS standard aliaes like monospace. But since you're ditching MSIE7 as too old one, i''m pretty sure you can rely that all current browsers do support standard aliases, and use the fonts user feels are best. For Linux there were Microsoft CoureirNew, URW, Vera, DejaVu, Liberation and what not Original 1955-designed Courier font with most popular implementation obsoleted 20 years ago is hardly a good choice i wanted to check Chrome and Mozilla, but cannot find russian text on xwiki.org and http://playground.xwiki.org/ only allows anonymous reading, not editing (sic! after i login it diallows me even read sandbox!) 4.2) in Opera courier new is getting quotations exactly like courier which means Opera deviates form standard by prohibiting Courier font despite being ready in system. But that deviation is what allows it render that style nicely. 4.3) all CSS tutorials i googled enumerate 5 standard values and Courier isnot among them. http://www.w3schools.com/cssref/pr_font_font-family.asp http://en.wikipedia.org/wiki/Font_family_(HTML)#Generic_font_families 4.4) Opera always had flexible font re-mapping, 10 years ago it was very needed without encodings support. http://help.opera.com/Linux/9.52/en/fonts.html The screenshots are http://imgur.com/a/UE4h5 - i feel they support thisidea. The comparision of liens at http://imgur.com/a/55Xrq also suggests it.4.5) i asked a question would see http://dev.opera.com/articles/view/fonts-for-web-design-a-primer/#comments Same effect i see on http://www.indeep76.com/Style/Example007/fonts.html Funny thing, on http://y3x.ru/sandbox/css/font-family/ it is the opposite picture. MSIE works with Courier+monospace nicely and Opera fails. -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ -- View this message in context: http://xwiki.475771.n2.nabble.com/Diff-font-is-tp7580425p7580619.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Diff font is
Sergiu Dumitriu-2 [via XWiki] ml-node+s475771n7580615...@n2.nabble.com писал(а) в своём письме Mon, 30 Jul 2012 19:22:58 +0400: Font names with spaces in them should be placed in quotes. Try: font-family: Courier New, monospace; I tried with single quotes (apostrophes), with double quotes and unquoted. no difference. Both browsers in their CSS inspectors have their own ideas when to render quotes and when not. Would i put them in CSS or not does not count for them. And frankly, since value of monospace alias is already Courier New for MSIE, it could not cause difference even if parse error happened The only thing needed was not to use 20+ years old bitmap font. Opera has hardcoded this deviation from standard, MSIE followed standard instead and... -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ -- View this message in context: http://xwiki.475771.n2.nabble.com/Diff-font-is-tp7580425p7580620.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] sources filename, why that redundancy ?
On 07/30/2012 02:50 PM, Arioch wrote: Marius Dumitru Florea [via XWiki] ml-node+s475771n7580616...@n2.nabble.com писал(а) в своём письме Mon, 30 Jul 2012 19:29:34 +0400: But what i noticed again, is that hugely redundant file naming xwiki-platform-core/xwiki-platform-classloader/xwiki-platfor m-classloader-protocols/xwiki-platform-classloader-protocol-attachmentjar/src/te st/java/org/xwiki/classloader/internal/protocol/attachmentjar/AttachmentURLStrea mHandlerTest.javaWhy that repeating time and gain, like if you use flat filesystem ratherthan tree ? It's a naming convention we agreed on: the maven module folder name should be the same as the maven module artifact ID. Well, if u chosen to keep all the genealogy in the folder name, modellign after flat 1D maven list, then folder structure can be kept flat too. Call it Windows limitations or Git/Win lack of intelligency, yet you casted aside all potential Windows-based developers. We are aware of the problem and we do plan on fixing it. But such a change will break lots of things, like existing pull request, forks, local checkouts... It's not easy to change the whole layout of a project that's widely cloned. -- Sergiu Dumitriu http://purl.org/net/sergiu/ ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
