I'm trying to build a Prisoner's Dilemma game in Z-Tree (the toolkit for building game theory experiments), and have encountered two irritating problems.
I haven't succeeded in applying formatting to the output inside of an item. Specifically, I'd like to display the number of years of prison each player gets at the end of a game, in the format:
Years of Prison: value
using the Layout dialogue of the Item box. Not using the layout and inserting the values directly into the text leads to a far too messy display.
Is there a way to do that using variables (conceptually, something like Payoff = {\rtf \fs30 Payoff}), and not concrete values (like !text: 1 = {\rtf \fs30 1}).
Is there a way to enable UTF-8 encoding? I have some letters (like č or š) which aren't being displayed correctly?
I'm using the latest Z-Tree version, on Linux ElementaryOS, running on Wine.
Answer to 1: In the label of your item, do this:
<>{\rtf Payoff = \fs30 <Payoff|0.1> }
Answer to 2: I do not know for sure. I think the font z-Tree uses by default does not support those characters. What I would try is to find a font that supports them and use it. In your code the characters will appear as weird symbols, but maybe in the leafs they'll be displayed correctly.
Related
If I have the axis label $x_\textrm{ABC}$, the ABC is way too big. I tried $x_\textrm{\scriptsize ABC}$ and $x_\textrm{\tiny ABC}$, but that prevents the LaTeX code from being interpretted (I end up seeing the raw code instead of the formatted math). How does one shrink the subscript text size when the subscript is a name that needs to be spelled in text mode?
I posted this to usenet yesterday, but no response so far.
I also tried to modify the text in Acrobat Pro, but I can't actually highlight the individual series of characters (it's the y-axis label).
Finally, I tried to modify it in inkscape, but same problem.
A respondent at the usenet link provided the answer: To use \mathrm instead of \textrm. It looks way better.
Matlab cannot display Arabic/Persian labels of the figure. Also I cannot see my installed fonts and I don't want to add the labels by another program. How can I fix this problem?
What you're looking for is a way to display unicode characters in axes labels.
It seems that this problem was encountered before, but there's no simple solution for it. See workarounds here and here.
One important thing though - do not edit .m files containing unicode\utf-8 characters (such as Arabic, Farsi, Hebrew, Chinese, etc...) in MATLAB, because it messes up the characters upon saving. Use an external editor (like Notepad++) to edit and save the files (as UTF-8 without BOM), and only run in MATLAB.
I am developing a Windows Mobile App that requires printing into a Zebra printer. Problem is, I do not have the printer with me here in my country since the client did not provide any.
My approach was to design a label first in ZebraDesigner2, then print out the label into a text file. Printing the label to a text file instead of a printer sends out the ZPL Code to produce the label I was trying to print. Hence, I can generate ZPL codes faster by designing a label first then seeing the ZPL code. Kinda like having a drag and drop GUI with a background XML.
Say that I have this simple label that contains this text:
Hello World!
If I print this in ZebraDesigner2 it would be written to my text file as:
CT~~CD,~CC^~CT~
^XA~TA000~JSN^LT0^MNW^MTT^PON^PMN^LH0,0^JMA^PR5,5~SD15^JUS^LRN^CI0^XZ
^XA
^MMT
^PW609
^LL0406
^LS0
^FT1,29^A0N,28,28^FH\^FDHello World!^FS
^PQ1,0,1,Y^XZ
My main question is, which one do I include in my C# Code if im going to send this code to the printer via my Windows Mobile C# app? Do I include the part with ^XA until ^XZ? I believe that CT~~CD,~CC^~CT~ should not be included in my code If im not mistaken.
Late answer, but since this is getting viewed...
The CT line and first set of XA..XZ sequence sets up the modes, label length, printable area, etc.
If you remove those, it will take those settings from the label/printer settings, which is usually what you want. The printers can sense the length and width of the label.
Leaving them in can cause big problems, because if you define the printable area in your label, and then the next label type submitted does not, it will use the settings you have defined -- which can cause blank areas in the label, eg. cutoff USPS Label barcodes that are printed after your Zebra Designer custom labels.
Found this out the hard way - leave those out, and you should leave out of the remaining XA..XZ sequence the MMT, PW609, LL0406, and LS0 as well - your Hello World will not be affected.
If you really want to limit the area printed to, set up margins inside the printable area, etc, refer to the manual.
you have to look at the programmers guide before you remove anything of the code. The CT~ command for example changes the control prefix.
Search the internet or zebra.com site for "ZPL Programming guide".
So, leave the text file as is and then include that into your windows mobile application.
PS: zebra offers SDKs for label/receipt printers: http://www.zebra.com/gb/en/products-services/software/adapt-software.html
PS2: without a test printer you may get bad final results.
This picture illustrates my predicament:
All of the characters appear to be the same size, but the space between them is different when presented in a RichEdit control compared with when I use ExtTextOut.
I would like to present the characters the same as in the RichEdit control (ideally), in order to preserve wrap positions.
Can anyone tell me:
a) Which is the more correct representation?
b) Why the RichEdit control displays the text with no gaps between the Asian Characters?
c) Is there any way to make ExtTextOut reproduce the behaviour of the RichEdit control when drawing these characters?
d) Would this be any different if I was working on an Asian version of Windows?
Perhaps I'm being optimistic, but if anyone has any hints to offer, I'd be very interested to hear.
In case it helps:
Here's my text:
快的棕色狐狸跳在懶惰狗1 2 3 4 5 6 7 8 9 0
apologies to Asian readers, this is merely for testing our Unicode implemetation and I don't even know what language the characters are taken from, let alone whether they mean anything
In order to view the effect by pasting these characters into a RichEdit control (eg. Wordpad), you may find you have to swipe them and set the font to 'Arial'.
The rich text that I obtain is:
{\rtf1\ansi\ansicpg1252\deff0\deflang2057{\fonttbl{\f0\fnil\fcharset0 Arial;}}{\colortbl ;\red0\green0\blue0;}\viewkind4\uc1\pard\sa200\sl276\slmult1\lang9\fs22\u24555?\u30340?\u26837?\u33394?\u29392?\u29432?\u36339?\u22312?\u25078?\u24816?\u29399?1 2 3 4 5 6 7 8 9 0\par\pard\'a3 $$ \'80\'80\cf1\lang2057\fs16\par}
It doesn't appear to contain a value for character 'pitch' which was my first thought.
I don't know the answer, but there are several things to suspect:
There are several versions of the rich edit control. Perhaps you're using an older one that doesn't have all the latest typographic improvements.
There are many styles and flags that affect the behavior of a rich editcontrol, so you might want to explore which ones are set and what they do. For example, look at EM_GETEDITSTYLE.
Many Asian fonts come in two versions on Windows. One is optimized for horizontal layout, and the other for vertical layout. That latter usually has the same name, but has # prepended to it. Perhaps you are using the wrong one in the rich edit control.
UPDATE: By messing around with Wordpad, I was able to reproduce the problem with the crowded text in the rich edit control.
Open a new document in Wordpad on Windows 7. Note that the selected font is Calibri.
Paste the sample text into the document.
Text appears correct, but Wordpad changed the font to SimSun.
Select the text and change the font back to Calibri or Arial.
The text will now be overcrowded, very similar to your example. Thus it appears the fundamental problem is with font linking and fallback. ExtTextOut is probably selecting an appropriate font for the script automatically. Your challenge is to figure out how to identify the right font for the script and set that font in the rich edit control.
This will only help with part of your problem, but there is a way to draw text to a DC that will look exactly the same as it does with RichEdit: what's called the windowless RichEdit control. It not exactly easy to use: I wrote a CodeProject article on it a few years back. I used this to solve the problem of a scrollable display of blocks of text, each one of which can be edited by clicking on it: the normal drawing is done with the windowless RichEdit, and the editing by showing a "real" RichEdit control on the top of it.
That would at least get you the text looking the same in both cases, though unfortunately both cases would show too little character spacing.
One further thought: if you could rely on Microsoft Office being installed, you could also try later versions of RichEdit that come with office. There's more about these on Murray Sargent's blog, as well as some interesting articles on font binding that might also help.
ExtTextOut allows you to specify the logical spacing between records. It has the parameter lpDx which is a const pointer to an array of values that indicate the distance between origins of adjacent character cells. The Microsoft API documentation notes that if you don't set it, then it sets it's own default spacing. I would have to say that's why ExtTextOut is working fine.
In particular, when you construct a EMR_EXTTEXTOUTW record in EMF, it populates an EMR_TEXT structure with this DX array - which looking at one of your comments, allowed the RichEdit to insert the EMF with the information contained in the record, whereby if you didn't set a font binding then the RTF record does some matching to work out what font to use.
In terms of the RichEdit control, the following article might be useful:
Use Font Binding in a Rich Edit Control
After character sets are assigned, Rich Edit scans the text around the
insertion point forward and backward to find the nearest fonts that
have been used for the character sets. If no font is found for a
character set, Rich Edit uses the font chosen by the client for that
character set. If the client hasn't specified a font for the character
set, Rich Edit uses the default font for that character set. If the
client wants some other font, the client can always change it, but
this approach will work most of the time. The current default font
choices are based on the following table. Note that the default fonts
are set per-process, and there are separate lists for UI usage and for
non-UI usage.
If you haven't set the characterset, then it further explains that it falls back to ANSI_CHARSET. However, it's most definitely a lot more complicated than that, as that blog article by Murray Sargent (a programmer at Microsoft) shows.
I'm trying to output RTF (Rich Text Format) from a Ruby program - and I'd prefer to just emit RTF directly without using the RTF gem as I'm doing pretty simple stuff.
I would like to highlight specific characters in a DNA sequence alignment and from the docs it seems that I can either use \highlightN ... \highlight0 or \cbN ... \cb1
The problem is that I cannot get \cb to work in either Word:Mac 2008 or Mac TextEdit (\cf works fine so I know it's not a color table issue)
\highlight does work but seemingly only with two of the possible colors (black and red) and \highlight does not use the custom color table.
By creating simple docs in Word with character shading and saving as RTF I can see blocks of ridiculously verbose RTF code that presumably does what I want, but it is so impenetrable that I'm not seeing the wood for the trees.
Part of the problem may well be that Mac Word is just not implementing RTF properly. I don't have a Windows version of Word handy.
Anyone know the right way to shade blocks of text?
Thanks
--Rob
There is a note in the RTF Pocket Guide that says MS Word does not implement the \cb command. It says MS Word uses \chshdng0\chcbpatN (where "N" is the color number that you would use with \cb). The book recommends using something like the following for compatibility with programs that implement \cbN and/or \chshdng0\chcbpatN: {\chshdng0\chcbpat5\cb5 text}.
Note: The copy of the book I have was published in 2003, so it might be a bit out-of-date.
The sequence of RTF commands that seems to be most universally supported by RTF-capable applications is:
\chshdng10000\chcbpatN\chcfpatN\cbN
These commands:
set the shading to 100 percent
set the pattern foreground and background colors to the color from the color table (we're not actually specifying a shading pattern)
set the character background to the color from the color table
Word was the most difficult application to properly render background colors in:
Despite what the latest (1.9.1) RTF spec says, Word 2013 does not resolve \highlightN colors from the \colortbl. Instead, \highlightN maps to a predefined list of colors. It looks like those colors come from the 1.5 version of the RTF spec.
Regarding \cb, the 1.9.1 spec contains this helpful pointer at the end of the section on Color Table:
Note: Windows versions of Word have never supported \cbN, but it can be emulated by the control word sequence \chshdng0\chcbpatN.
This is almost a useful suggestion, except that if you read the documentation for \chshdngN:
Character shading. The N argument is a value representing the shading of the text in hundredths of a percent.
So, 0 turns out to not be a very useful value; 100 / 0.01 gives us the 10000 we used in the sequence above.
Use WordPad to create RTF documents, not Word. WordPad creates much simpler documents, i.e. approaching human-readable.
I use WordPad every time I need to display formatted text in a WinForms application, and need something that the RichTextBox control can handle being assigned to its Rtf parameter.