- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] JavaScript example
by Riaz 04 Nov '11

04 Nov '11

Hi, I had no luck on the users group, so I thought I would try my luck on the devs group. I would like to add the javascript below to my xwiki page. Is this something that can easily be done? If so please can you show me an example. Thanks Riaz google.load('visualization', '1', {'packages':['table']}); function changeData(scorer) { var whereClause = ""; if(scorer) { whereClause = " WHERE 'Scoring Team' = '" + scorer + "'"; } var queryText = encodeURIComponent("SELECT 'Scoring Team', 'Receiving Team', 'Minute of goal' FROM 197026" + whereClause); var query = new google.visualization.Query('http://www.google.com/fusiontables/gvizdata?tq=' + queryText); query.send(getData); } function getData(response) { var table = new google.visualization.Table(document.getElementById('visualization')); table.draw(response.getDataTable(), {showRowNumber: true}); See this for more info: http://gmaps-samples.googlecode.com/svn/trunk/fusiontables/gviz_datatable.ht ml -----Original Message----- From: users-bounces(a)xwiki.org [mailto:[email protected]] On Behalf Of Riaz Sent: 28 October 2011 10:35 To: users(a)xwiki.org Subject: [xwiki-users] JavaScript example Hi, I'm new to XWiki, and I would like some help on how to add JavaScript to my pages. I have looked at the example SkinExtensionsTutorial and can now do basic JavaScript for example: alert ("HelloWorld"); via the JavaScriptExtension. I would like to add Google fusion tables to my Xwiki page an example of what I am after is below with the JavaScript: http://gmaps-samples.googlecode.com/svn/trunk/fusiontables/gviz_datatable.ht ml The JavaScript is shown below: google.load('visualization', '1', {'packages':['table']}); function changeData(scorer) { var whereClause = ""; if(scorer) { whereClause = " WHERE 'Scoring Team' = '" + scorer + "'"; } var queryText = encodeURIComponent("SELECT 'Scoring Team', 'Receiving Team', 'Minute of goal' FROM 197026" + whereClause); var query = new google.visualization.Query('http://www.google.com/fusiontables/gvizdata?tq=' + queryText); query.send(getData); } function getData(response) { var table = new google.visualization.Table(document.getElementById('visualization')); table.draw(response.getDataTable(), {showRowNumber: true}); How can I add this information to my Xwiki page. Your help is much appreciated. Best Regards, Riaz _______________________________________________ users mailing list users(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/users

4 4

[xwiki-devs] [VOTE] Add new LinkChecker modules in xwiki-platform
by Vincent Massol 03 Nov '11

03 Nov '11

Hi devs, I'd like to create the following modules in xwiki-platform to add a UI for the linkchecker feature: xwiki-platform-linkchecker/ |_ xwiki-platform-linkchecker-ui/ |_ xwiki-platform-linkchecker-refresher/ where: * xwiki-platform-linkchecker-ui/ will add a Tab in Main.AllDocs to list broken external links. It'll contain the livetable that you can see on http://www.xwiki.org/xwiki/bin/view/Admin/ExternalLinkStatus * xwiki-platform-linkchecker-refresher/ will contain an EventListener listening to DocumentUpdatingEvent and remove all link states from the link state cache for the modified pages received as Events. This module will depend on the LinkChecker Transformation module located in xwiki-rendering. Here's my +1 Thanks -Vincent

7 8

[xwiki-devs] About the AdminTools extension
by Maxime Sinclair 02 Nov '11

02 Nov '11

Hello Devs, As a XWiki admin, I installed the AdminTools extension (http://extensions.xwiki.org/xwiki/bin/view/Extension/AdminTools) The configuration check pages are very useful to verify a fresh install, the export pages are priceless (especially the Admin.Export one)... Of course, these pages are not very polished but they do the job. Fortunately, this extension is maintained as a contribution in Github. In the extension wiki, it would be fine to clearly mention that "Import Export Application", "Monitoring Application", "XAR Diff Application" are now included in the AdminTools (as it is for the "Check Config And Indexes Application"). Maybe I miss one or two. If you agree, I can do it. By the way, I submitted a few days ago a pull request to add a new ShrinkTrashBin page in AdminTools. Don't forget it. Maxime

3 4

[xwiki-devs] [Proposal] Livetable macro as a XWiki Syntax 2.0 macro
by Vincent Massol 02 Nov '11

02 Nov '11

Hi devs, I've started designing the new livetable macro as a XWiki Syntax 2.0 macro. I've brainstormed with Jerome this morning and here's what we came up with: http://dev.xwiki.org/xwiki/bin/view/Design/LiveTable20Macro Feedback most welcome. I can add more information if something isn't clear (as there's very little doc ATM). Thanks -Vincent

1 0

Re: [xwiki-devs] [xwiki-users] [Announcement] XWiki Enterprise and XWiki Enterprise Manager 3.3 Milestone 1 Released
by Sergiu Dumitriu 02 Nov '11

02 Nov '11

On 11/02/2011 06:51 AM, shouldbe q931 wrote: > Has any testing been done with Oracle ? Fixing the Oracle problems was one of my targets for this release, but it's so hard to get a local working instance of Oracle 10g installed. I'll spend more time on this after I finish my assigned workload for 3.3 > On Tue, Nov 1, 2011 at 4:12 AM, Sergiu Dumitriu<sergiu(a)xwiki.com> wrote: >> The XWiki development team is proud to announce the availability of XWiki >> Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and XWiki >> Enterprise Manager 3.3 Milestone 1. Since we're getting closer to the end of >> the 3.x cycle, there are fewer new features in this release, most of the >> changes being internal. The highlights of this release are: >> >> * a preview version of the new class editor to be used in the Application >> Within Minutes designer >> * new Debian packages for XWiki >> * a few extension manager improvements >> * LDAP improvements >> * improvements on uploading and downloading attachments, especially when >> filesystem storage is enabled >> >> And on the developers' front: >> >> * script services for Application Manager and Wiki Manager >> * cache improvements >> * changes in the way XAR modules are packaged >> * and the usual dependency upgrades and translation improvements >> >> See the full release notes at >> http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise33M1 >> for more details. -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0

[xwiki-devs] [VOTE] Should "delete" rights be considered at the document level?
by Sergiu Dumitriu 02 Nov '11

02 Nov '11

Rights have different scopes in XWiki. Administration rights can only be set on a space or wiki level, and any "admin" right set on a document alone will be silently ignored. Programming rights are only considered when set on the xwiki:XWiki.XWikiPreferences document, being ignored in any other virtual wiki and at the space or document level. Delete rights are a bit special as well. By default, the creator of a document has delete rights on that document. Unlike the other rights which default to true when no right is set, this one defaults to false. So, by default, when no "delete" rights are set on the document/space/wiki, only the creator of a document and administrators are allowed to delete it. Should we allow setting the delete right at the document level? Personally, I'd say no, since it's a rare requirement for a non-creator to be able to delete just one document. Space-level rights should be enough, IMO. -- Sergiu Dumitriu http://purl.org/net/sergiu/

3 4

[xwiki-devs] Technical name for "Application Within Minutes"
by Marius Dumitru Florea 02 Nov '11

02 Nov '11

Hi devs, We need to decide on a technical name for the "Application Within Minutes", i.e. the name of the platform module and the name of the space that will hold the Application Within Minutes pages. For now I committed my code in xwiki-platform-applicationWithinMinutes and I used the "ApplicationWithinMinutes" space name but this is not consistent with the way we named modules and spaces so far. Do you have any suggestions? We could use simply xwiki-platform-application, but it collides with xwiki-platform-application-manager, and I don't think it's a good idea to merge them. Is application manager still used? Is it going to be replaced by the extension manager? Thanks, Marius

4 6

[xwiki-devs] [VOTE] Which font faces to use for exporting CJK (Chinese/Japanese/Korean) characters in PDFs? (was: PDF export, chinese characters displayed as #, XE3.2)
by Sergiu Dumitriu 02 Nov '11

02 Nov '11

Hey community, I spent some time trying to make PDF export work for CJK (Chinese, Japanese, Korean) characters, and managed to get it working quite well. Searching for some good open source fonts, I finally decided on the following: - CJK Unifonts (Linux re-packaging of the Arphic fonts) - IPAGothic - Baekmuk The first one comes in two variants, serif (a.k.a. ming or song) and script (regular script, kai), and has good support for Chinese, with good, but not complete, support for Japanese, and no support for Korean. It looks very good in both variants, but we should decide on one of them. I uploaded samples on http://jira.xwiki.org/browse/XWIKI-7106 to see how they would look. *** Q1: Should Kai or Ming be used as the default export font for Chinese? *** I'm far from being an expert here, but my opinion is that the Kai variant, with it's handwritten look, is better suited for printed material. Still, PDFs are also used on screen, be that a large computer monitor or a handheld device, and on screen the legibility of the Ming variant is better. One option that I like is to use Kai for normal text and Ming for tt/code elements, as a kind of monospace. The second font, IPAGothic, is centered on Japanese, so it has good support for Japanese, some support for Chinese, and no support for Korean. It is a sans-serif variant. The third font, Baekmuk, brings support for Korean (laking from the other two fonts), along with little support for some Chinese and Japanese characters. This one comes in more variants, but only two are complete enough to be considered, Batang as the serif equivalent, and Gulim as the sans-serif equivalent. *** Q2: Should Batang or Gulim be used for Korean? *** My opinion is that the serif variant looks better on print, although less readable. Still, I've seen Gulim much more often used in practice. I attached two samples for this as well to the Jira issue. *** Q3: Should the current FreeSerif font be used for non-CJK characters, or the font face defined in the font specific to each language? *** While I prefer FreeSerif for all English text, I've seen in practice that the preferred solution is to use a bulkier font for numbers and latin characters. *** Q4: Does italics/oblique make sense for CJK characters? *** The concept of Italics is defined only for latin-like characters, and no font provides support for italics CJK. Still, Firefox does render slanted characters for CJK text inside <em>. FOP, the rendering engine used for generating PDFs, does not have support for automatically slanting fonts that don't provide an italics variant, and will insist on choosing a font that comes in an italics variant. So, this means that by default any text that is emphasized in the wiki will not be displayed in the PDF correctly (they would appear as # characters). There is a simple solution, and that is to alter the font file so that is says that both the regular and italic version of the font are in the file. Another option is to actually provide an oblique version of the font, which FontForge seems to be able to do quickly and with good results. Still, this will double the size of the fonts, so I'd rather not provide italic fonts if they don't actually make much sense for native CJK users. Some other fonts that I looked at were: * the Droid font used in Android devices, which is a sans-serif font IMO not suited for print; its advantage would be that it provides a unitary look for all CJK languages, less good looking, but more legible * the Hanazono font, which has impressive support for all the characters in CJK Unicode sets, but was created in a wiki way, so IMO it's not very consistent throughout the whole spectrum, and not as esthetically looking as the others *** Q5: Should a less good looking, but smaller and more consistent font be used? If yes, which one? *** The Droid font is actually quite small compared to the others, and on smaller font sizes it is more readable. I would really appreciate some feedback on this topic. -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 1

Re: [xwiki-devs] [xwiki-users] [VOTE] Which font faces to use for exporting CJK (Chinese/Japanese/Korean) characters in PDFs?
by Sergiu Dumitriu 02 Nov '11

02 Nov '11

On 11/02/2011 01:45 AM, Yang Li wrote: > ? 2011/11/2 12:00, Sergiu Dumitriu ??: >>>> *** >>>> Q1: Should Kai or Ming be used as the default export font for Chinese? >>>> *** >>>> >>>> I'm far from being an expert here, but my opinion is that the Kai >>>> variant, with it's handwritten look, is better suited for printed >>>> material. Still, PDFs are also used on screen, be that a large >>>> computer monitor or a handheld device, and on screen the legibility of >>>> the Ming variant is better. One option that I like is to use Kai for >>>> normal text and Ming for tt/code elements, as a kind of monospace. >>>> >>> As a Chinese, I strongly recommend *song* , the most poluar font, and we >>> seldom use ming in official documents... >> >> Reading on Wikipedia I got the impression that there isn't a clear >> distinction between Ming and Song, and some refer to the same thing >> with both terms. Looking at the list of CJK fonts >> http://en.wikipedia.org/wiki/List_of_CJK_fonts none of the fonts that >> have Song in their name are under an open source friendly license, so >> they can't be redistributed. Please take a look at the sample PDF and >> see if it is acceptably similar to Song: >> http://jira.xwiki.org/secure/attachment/23886/ming-over-freefont.pdf > According to the wikipedia > http://en.wikipedia.org/wiki/Ming_%28typefaces%29 > ------------------------------------------------------------------------ > The names Song (or Sung) and Ming correspond to the Song Dynasty > <http://en.wikipedia.org/wiki/Song_Dynasty> when a distinctive printed > style of regular script <http://en.wikipedia.org/wiki/Regular_script> > was developed, and the Ming Dynasty > <http://en.wikipedia.org/wiki/Ming_Dynasty> during which that style > developed into the Ming typeface style.^[1] > <http://en.wikipedia.org/wiki/Ming_%28typefaces%29#cite_note-kinkido-0> > In Mainland China, the most common name is Song (the Mainland Chinese > standardized Ming typeface in Microsoft Windows > <http://en.wikipedia.org/wiki/Microsoft_Windows> being named SimSun). In > Hong Kong <http://en.wikipedia.org/wiki/Hong_Kong>, Taiwan > <http://en.wikipedia.org/wiki/Taiwan>, Japan > <http://en.wikipedia.org/wiki/Japan> and Korea > <http://en.wikipedia.org/wiki/Korea>, Ming is prevalent. In Hong Kong > and Taiwan, "Song typeface" (??) has been used but "Ming typeface" (??) > has increased currency since the advent of desktop publishing > <http://en.wikipedia.org/wiki/Desktop_publishing>. Some type foundries > <http://en.wikipedia.org/wiki/Type_foundry>^[2] > <http://en.wikipedia.org/wiki/Ming_%28typefaces%29#cite_note-1> use > "Song" to refer to this style of typeface that follows a standard such > as the Standard Form of National Characters > <http://en.wikipedia.org/wiki/Standard_Form_of_National_Characters>, and > "Ming" to refer to typefaces that resemble forms found in the Kangxi > dictionary <http://en.wikipedia.org/wiki/Kangxi_dictionary>. > ------------------------------------------------------------------------ > Ming and Song (or Sung) is different indeed, and Song is popular in > Mainland China while Ming is popular in HK, TW, or JP and so on. They > are similar, however, Song has more sharp angles or corners than Ming, > while Ming has smooth ones, illustrated in the following two > pictures(Ming and Song): > > Actually, there seems to be both Ming and Song available according to > http://en.wikipedia.org/wiki/Arphic_Public_License#Arphic_Public_License > But I cannot find where to download the fonts... Yeah, tell me about it, in the end I used the ones repackaged in CJKUnifonts, which only provide UKai and UMing. After searching some more I found their Song variant, but it's older and less complete than the other two. Anyway, thanks a lot for the feedback, you've been of great help. -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0

Re: [xwiki-devs] [xwiki-users] [VOTE] Which font faces to use for exporting CJK (Chinese/Japanese/Korean) characters in PDFs?
by Sergiu Dumitriu 02 Nov '11

02 Nov '11

On 11/01/2011 11:07 PM, Yang Li wrote: > ? 2011/11/2 10:46, Sergiu Dumitriu ??: >> Hey community, >> >> I spent some time trying to make PDF export work for CJK (Chinese, >> Japanese, Korean) characters, and managed to get it working quite well. >> >> Searching for some good open source fonts, I finally decided on the >> following: >> >> - CJK Unifonts (Linux re-packaging of the Arphic fonts) >> - IPAGothic >> - Baekmuk >> >> The first one comes in two variants, serif (a.k.a. ming or song) and >> script (regular script, kai), and has good support for Chinese, with >> good, but not complete, support for Japanese, and no support for >> Korean. It looks very good in both variants, but we should decide on >> one of them. I uploaded samples on >> http://jira.xwiki.org/browse/XWIKI-7106 to see how they would look. >> >> *** >> Q1: Should Kai or Ming be used as the default export font for Chinese? >> *** >> >> I'm far from being an expert here, but my opinion is that the Kai >> variant, with it's handwritten look, is better suited for printed >> material. Still, PDFs are also used on screen, be that a large >> computer monitor or a handheld device, and on screen the legibility of >> the Ming variant is better. One option that I like is to use Kai for >> normal text and Ming for tt/code elements, as a kind of monospace. >> > As a Chinese, I strongly recommend *song* , the most poluar font, and we > seldom use ming in official documents... Reading on Wikipedia http://en.wikipedia.org/wiki/Ming_%28typefaces%29 I got the impression that there isn't a clear distinction between Ming and Song, and some refer to the same thing with both terms. Looking at the list of CJK fonts http://en.wikipedia.org/wiki/List_of_CJK_fonts none of the fonts that have Song in their name are under an open source friendly license, so they can't be redistributed. Please take a look at the sample PDF and see if it is acceptably similar to Song: http://jira.xwiki.org/secure/attachment/23886/ming-over-freefont.pdf >> The second font, IPAGothic, is centered on Japanese, so it has good >> support for Japanese, some support for Chinese, and no support for >> Korean. It is a sans-serif variant. >> >> The third font, Baekmuk, brings support for Korean (laking from the >> other two fonts), along with little support for some Chinese and >> Japanese characters. This one comes in more variants, but only two are >> complete enough to be considered, Batang as the serif equivalent, and >> Gulim as the sans-serif equivalent. >> >> *** >> Q2: Should Batang or Gulim be used for Korean? >> *** >> >> My opinion is that the serif variant looks better on print, although >> less readable. Still, I've seen Gulim much more often used in >> practice. I attached two samples for this as well to the Jira issue. >> >> *** >> Q3: Should the current FreeSerif font be used for non-CJK characters, >> or the font face defined in the font specific to each language? >> *** >> >> While I prefer FreeSerif for all English text, I've seen in practice >> that the preferred solution is to use a bulkier font for numbers and >> latin characters. > FreeSerif is good. OK, noted. >> >> *** >> Q4: Does italics/oblique make sense for CJK characters? >> *** >> >> The concept of Italics is defined only for latin-like characters, and >> no font provides support for italics CJK. Still, Firefox does render >> slanted characters for CJK text inside <em>. FOP, the rendering engine >> used for generating PDFs, does not have support for automatically >> slanting fonts that don't provide an italics variant, and will insist >> on choosing a font that comes in an italics variant. So, this means >> that by default any text that is emphasized in the wiki will not be >> displayed in the PDF correctly (they would appear as # characters). >> There is a simple solution, and that is to alter the font file so that >> is says that both the regular and italic version of the font are in >> the file. Another option is to actually provide an oblique version of >> the font, which FontForge seems to be able to do quickly and with good >> results. Still, this will double the size of the fonts, so I'd rather >> not provide italic fonts if they don't actually make much sense for >> native CJK users. >> > In fact, Chinese people use bold font to emphasize (hei), not italics, > and we seldom use italics. OK, so this means that italics doesn't make sense, which is good. The bad news is that FOP doesn't support making characters bold when there's no predefined font, either, but it won't fall back to a font that does provide bold. This means that bold text will appear the same way as regular CJK. I tried to generate a bold font from FontForge, but it fails with an error message: "some fragments did not join". So, our hope is that FOP will implement this feature soon. >> >> Some other fonts that I looked at were: >> * the Droid font used in Android devices, which is a sans-serif font >> IMO not suited for print; its advantage would be that it provides a >> unitary look for all CJK languages, less good looking, but more legible >> * the Hanazono font, which has impressive support for all the >> characters in CJK Unicode sets, but was created in a wiki way, so IMO >> it's not very consistent throughout the whole spectrum, and not as >> esthetically looking as the others >> >> *** >> Q5: Should a less good looking, but smaller and more consistent font >> be used? If yes, which one? >> *** >> >> The Droid font is actually quite small compared to the others, and on >> smaller font sizes it is more readable. >> > I prefer normal fonts, because nowadays we usually use a browser and > large display @@.. >> >> I would really appreciate some feedback on this topic. > -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0