Seeing as this is homework, I will not provide a complete answer here (maybe after a couple weeks have safely passed). But, I will provide a couple of pointers regarding your code.
Point 1: Excess whitespce
You've got a lot of excess whitespace creeping into your solution. Blank lines, in particular, will be treated as new paragraphs---probably not want you intended to do. All your lines ending in anything other than a control sequence are also creating spurious whitespace. Put a comment at the end of each of those lines to keep the whitespace out. Whitespace at the beginning of the line isn't a problem, though.
Point 2: Legal control sequence names
Control sequence names cannot be defined using non-alphabetic characters. So, you'll not be able to define a control sequence \x1 directly using \newcommand (there are ways to do this, but you don't need them here). Instead, you could define \newcommand\tmpxi, \newcommand\tmpxii, and so forth.
Point 3: \numexpr vs \dimexpr
\numexpr is only going to work with integer values. If you feed it something that is not an integer, then it will truncate the number. If you want to manipulate lengths use \dimexpr. However, PostScripts will not be expecting you to feed it units. So you need a method for pealing the units off of your lengths before you feed them to the PostScript code. You can do that with \strip@pt
For example, you might want to define
\makeatletter
\newcommand\tmpxi{\strip@pt\dimexpr\x-\length}
\makeatother
The \makeat... are necessary to get @ to behave as an alphabetic character (see point 2 above).
Point 4: Getting the desired coordinate matrix for PostScripts
You'll probably want to use \special{" instead of \special{ps: so that PostScripts obeys the lengths that you want. See my own question about this for an explanation
Point 5: whitespace following control sequences
After a control sequence, white space will be gobbled up. This can potential have unintended affects with your PostScript code. For example,
with
\def\tmpxi{10}
\special{"
0 0 moveto
\tmpxi 0 lineto
stroke
}
you'll get an error because after LaTeX reads this it will ship it off to the dvi driver as
0 0 moveto
100 lineto
stroke
to get around this you can write
\def\tmpxi{10}
\special{"
0 0 moveto
\tmpxi\space 0 lineto
stroke
}
Point 6: Absolute vs. Relative commands
You'll probably have an easier time of it if you use the relative commands rmoveto and rlineto. That way you don't need to worry too much about where currentpoint is.
Suggestion 1: saveboxes
If you want to wrap a particular word, you could create a command to save the word to a box, measure the dimensions of the box, and then use those dimensions to more easily calculate where to draw the lines.
For example
\newsavebox\mycontentbox
\newcommand\myoval[1]{%%
\sbox\mycontentbox{#1}%%
\def\mywidth{\wd\mycontentbox}%%
...
}
Other commands to access dimensions are
\dp=depth
\ht=height (above the baseline)
Final Result
Sticking with these general principles, this is what I can easily produce (box, not oval though)
One final point, at no point in my work did I have to refer to currentpoint. Additionally you should note that I made no corrections for how the box itself rudely intrudes upon the space surrounding it.
Solution
Here's a solution. There are a couple of things to note. First of all, I avoid creating LaTeX macros as much as possible. They're not necessary; postscript can do all the arithmetic calculations necessary. Secondly, now that I see some more of what you've put together, I would define the macros and everything else you need in the preamble to your document, not the body. Thirdly, I'm very sloppy about how I create the stripes for the background: in particular, I don't pay much heed to where they should begin or end with respect to the box itself. To make things terminate where I want them to terminate, I create the path and then invoke postscript's clip. Finally, I define several functions in postscript code to make the code for the paths and the code for the stripes easier to read.
\documentclass{article}
\usepackage[margin=1in]{geometry}
\makeatletter
\newsavebox\myovalbox
\newcommand\myoval[1]{%%
\sbox\myovalbox{#1}%%
\special{"
/mytxtht \strip@pt\ht\myovalbox\space def
/mytxtdp \strip@pt\dp\myovalbox\space def
/mytxtwd \strip@pt\wd\myovalbox\space def
%%
/mytxtboxsep 3 def
/myboxwd { mytxtboxsep dup add mytxtwd add } def
/myboxdp { mytxtboxsep mytxtdp add } def
/myboxht { mytxtboxsep dup add mytxtht mytxtdp add add } def
%%
/myboxhstart { mytxtboxsep neg } def
/myboxvstart { myboxdp neg } def
%%
/myinterstripesep 4 def
/mystripeprotrusion 6 def
/mystriperise { mystripeprotrusion dup add myboxht add } def
/mystriperun 8 def
/mystripebot { mystripeprotrusion myboxdp add neg } def
/mystripestart { mytxtboxsep dup add myinterstripesep add neg } def
/mystripeend { mytxtboxsep myboxwd add} def
%% draw the box
newpath
1 0 0 setrgbcolor
myboxhstart myboxvstart moveto
myboxwd 0 rlineto
0 myboxht rlineto
myboxwd neg 0 rlineto
closepath
clip
%% for loop: start-value increment end-value { iteration action } for
%% the for loop takes the current value of the loop and
%% places it at the beginning of iteration action, hence
%% the "moveto" below appears to only have one argument
mystripestart myinterstripesep mystripeend
{ mystripebot moveto
mystriperun mystriperise rlineto
}
for
stroke
%%
}%%
\usebox{\myovalbox}}
\makeatother
\begin{document}
This is an example of what I need to do in my program using \myoval{Postscript in LaTeX} program.
\end{document}
There are quite a few resources available on-line for postscript coding. There are some nice resources suggested at posted at this site. Namely,
A final note about \def vs \newcommand
It might be worth your time to peruse the question and answers to What is the difference between \def and \newcommand. It is very easy to misuse \def and bludgeon essential commands out of existence with disastrous effects on your code. My own approach with \def and \newcommand is to use \newcommand for commands I intend to use at the document (user interface) level. I use \def for the underlying commands that make the user level interface do what I want. And, a fair number of people on this site seem to take this approach. If you're not sure what macro names are already taken, then you can take the following approach
\newcommand\mymacroname{}
\def\mymacroname{<my real definition>}
The advantage to this approach is that if \mymacroname is already defined, you'll be issued a warning by \newcommand and you won't accidentally bludgeon something you may rely upon (and there is a lot of macros you rely upon without knowing it). You might wonder, if I do this why bother with \def? Well, with \def you can pass arguments in manners not conventional to \newcommand. There is a package xparse which actually allows you to create such non-conventional approaches in a much less dangerous way than \def does: it could be worth a read through.
The second thing I do when I use \def is to provide it a complex name the makes clear three things: (1) that I'm its author, (2) what I'm using it for, (3) what it's meant to do. So, for the macro \myoval above, I might have had various macros named:
\def\ae@boxtext@determine@dimensions#1{....}
where ae signals who I am, boxtext signals what I'm using this command for, and determine@dimensions says something about what the macro is supposed to do.
rmovetoandrlinetofor relative directives with respect to your current point. – A.Ellett May 06 '15 at 21:41\pdfliteralinstead direct PostSript. You can use simple vocabulary: q=gsave, Q=grestore, m=moveto, c=curveto etc. My macros are more complicated than in PostScript case because PDF has no rlineto, rcurveto counterparts, so, I have to calculate relative coordinates at macro level. – wipet May 07 '15 at 05:20\pdfliteral. – A.Ellett May 07 '15 at 14:12