[Pharo-users] [smallwiki] Pillar annotations for Latex

Hi Ben,

On Thu, May 22, 2014 at 6:09 PM, Ben Coman [hidden email] wrote:
> Now is there any important function missing, or is there a better way to do
> this?

thank you for your contribution.

I would try to generate this instead:

    \begin{note}
      foo bar baz
    \end{note}

This environment is meant for this. To output the \begin and \end parts, use

    canvas environment

(look at the senders of #environment in the PRLaTeXWriter class for examples)

To output the text, you can just write

   super visitAnnotatedParagraph: aParagraph


> I also want add an annotation type, which I'll describe in a following post.


I should we should think a bit how these should be handled. In the
meantime, you can just hack around :-). And please add unit tests.

-- 
Damien Cassou

So I determined that the following works well...


to process Pillar markup...


to produce this nice looking PDF showing the note indented with dividing lines...



Now that was real easy to do!! Thanks for making Pillar accessible. I can't imagine making a similar change as easy in a Markdown processor in some other language.

---------------
Next, in common.tex [1] I found...

and discovered I could do this in the Pillar markup...

to produce in the PDF two Pharo icons on separate lines...




But that is awkward and verbose to do each time, and I though it would be nice for Pillar to handle this as an annotation like this...
 
so I found I could do that by added the following hack to PRLaTeXWriter>>visitAnnotatedParagraph: ...
    'dothis' = anAnnotatedParagraph annotation asLowercase
        ifTrue:
        [     ^ self writeRawDuring:
            [    stream newLine.    
                stream << '\dothis{' .
                stream << anAnnotatedParagraph text trimBoth .
                stream << '} ' .
            ].
        ].

However changing this to be less of a hack like this...
    'dothis' = anAnnotatedParagraph annotation asLowercase
        ifTrue:
        [     ^ canvas command
                name: 'dothis' ;
                parameter: [  super visitAnnotatedParagraph: anAnnotatedParagraph ]
        ].
   
doesn't quite work, since the first Pharo icon runs onto the previous line...



That can be fixed as follows....

but I don't know if that is the right thing to do.  Maybe there are times when you want commands to run on from a line. What would be the right thing?

Also, is it reasonable to add this new annotation type?  i.e. might it be integrated soon ? :) :) . This would really help with the Laser Game tutorial.

[1] https://github.com/bencoman/PharoLaserGameTutorial/blob/master/common.tex

cheers -ben

P.S. This is my first post to the mail list using PostBox on OSX.  Let me know if you notice any issues with it being not plain text and if you have any advice ensure plain text posts in PostBox.



_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Ben Coman wrote:

Hi Ben,

On Thu, May 22, 2014 at 6:09 PM, Ben Coman [hidden email] wrote:
> Now is there any important function missing, or is there a better way to do
> this?

thank you for your contribution.

I would try to generate this instead:

    \begin{note}
      foo bar baz
    \end{note}

This environment is meant for this. To output the \begin and \end parts, use

    canvas environment

(look at the senders of #environment in the PRLaTeXWriter class for examples)

To output the text, you can just write

   super visitAnnotatedParagraph: aParagraph


> I also want add an annotation type, which I'll describe in a following post.


I should we should think a bit how these should be handled. In the
meantime, you can just hack around :-). And please add unit tests.

-- 
Damien Cassou

So I determined that the following works well...

PRLaTeXWriter>>visitAnnotatedParagraph: anAnnotatedParagraph
    "Pier seams to lack consistency here ..."

    'todo' = anAnnotatedParagraph annotation asLowercase
        ifTrue: [ ^ self visitCommentedLine: anAnnotatedParagraph ].
   
    canvas environment
        name: 'note' ;
        with: [  super visitAnnotatedParagraph: anAnnotatedParagraph ].

to process Pillar markup...

@@note Pay attention to the class definition for your new ""==BlankCellTest=="". It must be a subclass of the class ""==TestCase=="". This is easy to overlook. If you did it wrong already, no problem, just go back and correct it now and then save the code again.

Within a class, methods are organised into "protocols" that are shown in the third browser pane from the left of Figure *testCellStateShouldBeOffEmpty*.  We will group our "tests" inside a protocol of the same name.

to produce this nice looking PDF showing the note indented with dividing lines...



Now that was real easy to do!! Thanks for making Pillar accessible. I can't imagine making a similar change as easy in a Markdown processor in some other language.

---------------
Next, in common.tex [1] I found...

{
        \newcommand{\dothisicon}{\raisebox{-.5ex}{\includegraphics[height=1.2em]{pharo}}}
        \newcommand{\dothis}[1]{%
                \medskip
                \noindent\dothisicon
                \ifx#1\empty\else\quad\emph{#1}\fi
                \par\smallskip\nopagebreak}
}

and discovered I could do this in the Pillar markup...

Before defining a class we should define a package to contain our classes. When we save a package all the classes will be saved together. It is a good practice to group together classes that work together.
 
{{{latex:
\dothis{Right-click on the background and open a System Browser.}
\dothis{In the package list of the System Browser, choose "add package" to add a new package. Use the name "LaserG
}}}

to produce in the PDF two Pharo icons on separate lines...




But that is awkward and verbose to do each time, and I though it would be nice for Pillar to handle this as an annotation like this...

Before defining a class we should define a package to contain our classes. When we save a package all the classes will be saved together. It is a good practice to group together classes that work together.

@@dothis Right-click on the background and open a System Browser.

@@dothis In the package list of the System Browser, choose "add package" to add a new package. Use the name "LaserGame-Model".

 
so I found I could do that by added the following hack to PRLaTeXWriter>>visitAnnotatedParagraph: ...
    'dothis' = anAnnotatedParagraph annotation asLowercase
        ifTrue:
        [     ^ self writeRawDuring:
            [    stream newLine.    
                stream << '\dothis{' .
                stream << anAnnotatedParagraph text trimBoth .
                stream << '} ' .
            ].
        ].

However changing this to be less of a hack like this...
    'dothis' = anAnnotatedParagraph annotation asLowercase
        ifTrue:
        [     ^ canvas command
                name: 'dothis' ;
                parameter: [  super visitAnnotatedParagraph: anAnnotatedParagraph ]
        ].
   
doesn't quite work, since the first Pharo icon runs onto the previous line...



That can be fixed as follows....

PRLaTeXCommand>>name: aString
    stream newLine.   "<---THIS LINE ADDED"
    stream
        << $\
        << aString

but I don't know if that is the right thing to do.  Maybe there are times when you want commands to run on from a line. What would be the right thing?

Also, is it reasonable to add this new annotation type?  i.e. might it be integrated soon ? :) :) . This would really help with the Laser Game tutorial.

[1] https://github.com/bencoman/PharoLaserGameTutorial/blob/master/common.tex

cheers -ben

I discovered that instead of modifying PRLaTeXCommand>>name: ,
that in PRLaTeXWriter>>visitAnnotatedParagraph: I could do...
    'dothis' = anAnnotatedParagraph annotation asLowercase
        ifTrue:
        [     canvas newLine.  "<----THIS LINE ADDED"
            ^ canvas command
                name: 'dothis' ;
                parameter: [  super visitAnnotatedParagraph: anAnnotatedParagraph ]
        ].

which seems better, but maybe still not the best.
cheers -ben


_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

 

[hidden email]

24 May 2014 8:24 pm

that's the right way I guess, thank you for your contribution. Please add related unit tests.

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without losing enthusiasm."
Winston Churchill

I started looking into the unit tests and it is interesting how the tests seem to be structured to align with the visitor pattern, with PRDocumentWriterTest defining many tests once which refer to methods returning requirements-strings that are overridden in subclasses.

Now PRDocumentWriterTest  currently has no test for annotations, and PRMarkdown>>visitAnnotatedParagraph: says "Pier seems to lack consistency here ...", so I thought I might have a go at ironing that out. To learn a bit more about the system I tried each of the exporters and found a problem with comments where they break lists, which is a bit constraining.  This can be demonstrated with the following file "test.pier"...
        nesting test
        # item 1
        ## item 11
        ## item 12
        % comment 1
        ## item 13

with the shell command... pharo pillar.image pillar export --to=pillar test.pier
which produces...
        nesting test
        # item 1
        ## item 11
        ## item 12
        % comment 1
        #
        ## item 13

which is different from the original with the addition of the second last line. I would expect the output to be the same.

Tracing through, I observe the #add: in the last line of...
PRCommentedLine class >> parse: aString with: aParser
    | stream content |
    stream := aString readStream.
    stream next: self markup size.
    content := stream upToEnd.
    ^ aParser add: (self content: content)
puts the CommentedLine under the first level of the PRDocument and a new OrderedList is created (Figure 1 - Before).

Now by changing that last line to...   
            ^ aParser addNested: (self content: content)
the CommentedLine is placed under the ListItem and a new OrderedList is not created (Figure 1 - After), and
--to=pillar produces...
        nesting test
        # item 1
        ## item 11
        ## item 12
        % comment 1
        ## item 13
identical to the original.

In the attached MCZ I added...
PRDocumentParser >> addNested: anObject
    self addNested: anObject to: self document

PRDocumentParser >>  addNested: anObject to: aGroup
    aGroup children isEmpty
        ifTrue: [  ^ aGroup add: anObject ].
    aGroup children last isGroup
        ifTrue: [ ^ self addNested: anObject to: aGroup children last ] .
    ^ aGroup add: anObject.

PRDocumentItem >> isGroup
    ^false

PRDocumentGroup >> isGroup
    ^true



For completeness, here are the other output formats.

--to=markdown before produces...
        nesting test
        1.  item 1
            1.  item 11
            2.  item 12
        1.
            1.  item 13
--to=markdown after produces...
        nesting test
        1.  item 1
            1.  item 11
            2.  item 12
            3.  item 13


--to=text before produces...
        nesting test
        1.  item 1
                1.  item 11
                2.  item 12
        1.
                1.  item 13
--to=text after produces...
        nesting test
        1.  item 1
                1.  item 11
                2.  item 12
                3.  item 13


--to=latex before produces...
        \begin{document}
        nesting test
        \begin{enumerate} \item  item 1
        \begin{enumerate} \item  item 11 \item  item 12
        \end{enumerate}
        \end{enumerate}
        \begin{enumerate} \item
        \begin{enumerate} \item  item 13
        \end{enumerate}
        \end{enumerate}
        \end{document}
--to=latex after produces...
        \begin{document}
        nesting test
        \begin{enumerate}
        \item  item 1
        \begin{enumerate} \item  item 11     \item  item 12     \item  item 13
        \end{enumerate}
        \end{enumerate}
        \end{document}
 

--to=html before produces...
    <div class="container">
    <p>nesting test</p>
    <ol><li> item 1
        <ol>    <li>item 11</li>      <li>item 12</li>    </ol> 
    </li></ol>
    <ol><li>
        <ol><li>item 13</li></ol>
    </li></ol>
    </div>
--to=html after produces...
    <div class="container">
    <p>nesting test</p>
    <ol><li>item 1
    <ol>   <li>item 11</li>    <li>item 12</li>    <li> item 13</li>   </ol>
    </li></ol>
    </div>


So, thats a small start. Anything obvious it might break?

cheers -ben



_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki