Within the text of a question, I want to include a number symbol (#) and a genuine one-em dash. How do I get these?
I tried just # for the former, and that looked OK in the delivered question, but when I try to download hardcopy, I get (obviously) a non-compile TeX error that "You can't use `macro parameter character #' in horizontal mode."
So next I tried using \# but then when the question is delivered I see the backslash (although the hardcopy download is OK).
Next I tried again using \# but now including:
Context()->texStrings;
Same problem!
Similarly, how do I get a genuine one-em dash in text to display as such in both the delivered question and in the generated hardcopy for download?
Is any of this documented somewhere?
You need to use the MODES() macro, which allows different output depending on the viewing mode. For example
$HASH = MODES(HTML => "#", TeX => "\#");
$EMDASH = MODES(HTML => "—", TeX => "---");
would define two variables that you could use in BEGIN_TEXT/END_TEXT blocks to insert a hash mark or em-dash.
Hope that does it for you.
Davide
Thanks. But ugh: so primitive and awkward!
Where in the documentation for question authors does this appear?
I was especially surprised that not even \(\text{\#}\) worked.
A similar situation arises with respect to boldface or italics. For example, <strong>...</strong> works for on-screen but certainly not for generated pdf.
Is this all a design shortcoming or oversight, or an utter necessity of the structure of WeBWorK?
Where in the documentation for question authors does this appear?
I was especially surprised that not even \(\text{\#}\) worked.
A similar situation arises with respect to boldface or italics. For example, <strong>...</strong> works for on-screen but certainly not for generated pdf.
Is this all a design shortcoming or oversight, or an utter necessity of the structure of WeBWorK?
For bold, enclose the text in ${BBOLD} and ${EBOLD},
similarly for italics. (You can omit the braces, around the
name, but sometimes you want to include them e.g., for
${HASH}24 as in your other question.)
All of this is documented in PGbasicmacros.pl :
pod2text $PGROOT/macros/PGbasicmacros.pl | more
at a shell prompt on the server, where $PGROOT is the
location of the pg directory on the server.
Alternatively, all of this is in the cvs repository:
http://cvs.webwork.rochester.edu
If you go to the repository then you want to be careful
to look at the same revision as is on the server you are
using.
-wb
similarly for italics. (You can omit the braces, around the
name, but sometimes you want to include them e.g., for
${HASH}24 as in your other question.)
All of this is documented in PGbasicmacros.pl :
pod2text $PGROOT/macros/PGbasicmacros.pl | more
at a shell prompt on the server, where $PGROOT is the
location of the pg directory on the server.
Alternatively, all of this is in the cvs repository:
http://cvs.webwork.rochester.edu
If you go to the repository then you want to be careful
to look at the same revision as is on the server you are
using.
-wb
Thanks for the tip about enclosing in braces.
Having documentation in the source macro file is of no use to most of our users, since we don't have any access beyond our own course.
But it's even undesirable to have the documentation in the source macro file on some other, publicly available URL: how does one know that's where to look? The facility in question could be something built into the core of WeBWorK, after all! How is one to know?
Having documentation in the source macro file is of no use to most of our users, since we don't have any access beyond our own course.
But it's even undesirable to have the documentation in the source macro file on some other, publicly available URL: how does one know that's where to look? The facility in question could be something built into the core of WeBWorK, after all! How is one to know?
The pod documentation is also available (without the source code) at
http://webwork.maa.org/doc/cvs/pg_CURRENT/
which you can get to from the author's section of the wiki.
(PG macro/library documentation from CVS)
As pointed out ${HASH}24 is a standard perl construction which will allow you to print #24 without a space. The MODE() construction is a very basic construction (hence the all caps name to indicate that it is probably not for everyday use and to keep it from being accidentally overwritten by question writers.). It is only visible in this context because ten years ago $HASH and $EM were not standard characters we expected to use in problems so we didn't make macros for them. It's easy enough to to add them to PGbasicmacros.pl and I'll put them on the list.
As with any volunteer open source organization the documentation is a bit disorganized, but there is actually quite a bit of it available on the wiki. I think it might be helpful, Murray, if you could summarize some of your experience over the last semesters in a way that would be helpful to WeBWorK newcomers and put it up on the wiki. This might include an organized linear introduction to the wiki documentation. Wiki's are great for many things but sometimes a bit overwhelming when you are just starting out.
Also if you have favorite techniques for writing problems that you have developed it would be really helpful to put them in the
"Index of problem techniques section" http://webwork.maa.org/wiki/Category:Problem_Techniques
indexed in a way that would help newcomers through the authorship start up phase. Gavin LaRose at U. of Michigan started this section and has a template that you can use so that the examples have a certain uniformity and are easy to read.
http://webwork.maa.org/doc/cvs/pg_CURRENT/
which you can get to from the author's section of the wiki.
(PG macro/library documentation from CVS)
As pointed out ${HASH}24 is a standard perl construction which will allow you to print #24 without a space. The MODE() construction is a very basic construction (hence the all caps name to indicate that it is probably not for everyday use and to keep it from being accidentally overwritten by question writers.). It is only visible in this context because ten years ago $HASH and $EM were not standard characters we expected to use in problems so we didn't make macros for them. It's easy enough to to add them to PGbasicmacros.pl and I'll put them on the list.
As with any volunteer open source organization the documentation is a bit disorganized, but there is actually quite a bit of it available on the wiki. I think it might be helpful, Murray, if you could summarize some of your experience over the last semesters in a way that would be helpful to WeBWorK newcomers and put it up on the wiki. This might include an organized linear introduction to the wiki documentation. Wiki's are great for many things but sometimes a bit overwhelming when you are just starting out.
Also if you have favorite techniques for writing problems that you have developed it would be really helpful to put them in the
"Index of problem techniques section" http://webwork.maa.org/wiki/Category:Problem_Techniques
indexed in a way that would help newcomers through the authorship start up phase. Gavin LaRose at U. of Michigan started this section and has a template that you can use so that the examples have a certain uniformity and are easy to read.
Having documentation in the source macro file is of no use to most of our users, since we don't have any access beyond our own course.
You can get to the more relevant author help pages from the links on the problem editor page within webwork. The "manpage" and "macro list" entries are a bit out of date but can still be useful -- the others are as current documentation as we have. The testing lab can be particularly useful for quickly trying things out. Enjoy.
You can get to the more relevant author help pages from the links on the problem editor page within webwork. The "manpage" and "macro list" entries are a bit out of date but can still be useful -- the others are as current documentation as we have. The testing lab can be particularly useful for quickly trying things out. Enjoy.
One solution would be to have the sysadmin
generate html from the POD, put it somewhere,
and announce it to the users (or at least to
those who'd like to compose problems). Then
the documentation would correspond to the
revision of the macro file on the server.
generate html from the POD, put it somewhere,
and announce it to the users (or at least to
those who'd like to compose problems). Then
the documentation would correspond to the
revision of the macro file on the server.
How do I tell what revision a .pg file is using on the server that houses my system when I don't have direct access to it -- just to my own course?
Sounds like a Catch-22.
Sounds like a Catch-22.
"Is this all a design shortcoming or oversight, or an utter necessity of the structure of WeBWorK?"
The complexity arises from the desire to maximize the number of display formats, and that arises from the desire to make the system flexible and convenient for users.
There might be "better" ways to do this now; maybe it could be simplified if we dropped support for certain display formats, refactored the relevant code, or incorporated some newer cpan modules, etc.
But my impression is that making such changes would require a pretty thorough understanding of how perl, latex, jsMath, html, xml, etc handle special characters, and how to make those work together. And these concerns suggest the more general issues of character encodings and localization.
So no, it's not a design shortcoming, and yes, maybe it could be improved, but there are a lot of issues to deal with.
The complexity arises from the desire to maximize the number of display formats, and that arises from the desire to make the system flexible and convenient for users.
There might be "better" ways to do this now; maybe it could be simplified if we dropped support for certain display formats, refactored the relevant code, or incorporated some newer cpan modules, etc.
But my impression is that making such changes would require a pretty thorough understanding of how perl, latex, jsMath, html, xml, etc handle special characters, and how to make those work together. And these concerns suggest the more general issues of character encodings and localization.
So no, it's not a design shortcoming, and yes, maybe it could be improved, but there are a lot of issues to deal with.
I was especially surprised that not even \(\text{\#}\) worked.
Well, it would have worked in some display modes, but not all. I expect
Davide
Well, it would have worked in some display modes, but not all. I expect
\(\#\) would have worked.Davide
Is this all a design shortcoming or oversight, or an utter necessity of the structure of WeBWorK?
Neither, it's a design "feature". As others have said, it is to make it possible to handle the different display modes. Certainly other approaches are possible. One is used by the prototype PGML processor, which is viewed as an alternative to the BEGIN_TEXT/END_TEXT approach to generating the text of a problem.
See
http://hosted2.webwork.rochester.edu/webwork2/cervone_course/PGML?login_practice_user=true
http://hosted2.webwork.rochester.edu/webwork2/cervone_course/PGML-examples/?login_practice_user=true
http://webwork.maa.org/wiki/SampleProblem4
http://webwork.maa.org/wiki/PGLabs
for more information.
Davide
Neither, it's a design "feature". As others have said, it is to make it possible to handle the different display modes. Certainly other approaches are possible. One is used by the prototype PGML processor, which is viewed as an alternative to the BEGIN_TEXT/END_TEXT approach to generating the text of a problem.
See
http://hosted2.webwork.rochester.edu/webwork2/cervone_course/PGML?login_practice_user=true
http://hosted2.webwork.rochester.edu/webwork2/cervone_course/PGML-examples/?login_practice_user=true
http://webwork.maa.org/wiki/SampleProblem4
http://webwork.maa.org/wiki/PGLabs
for more information.
Davide
Now something I should probably know but don't: How do I use the $HASH definition, e.g., to produce something like #24, with no space between the hash sign and the digit following it?
Just "$HASH 24" produces a space between, and "$HASH24" of course eats everything.
Just "$HASH 24" produces a space between, and "$HASH24" of course eats everything.