Looking for some tasks.

[jonsgreen]

Hey Prawn Team,

My outlines work is mostly done though the finishing touches got hung
up by on some last minute changes to the #page method. I am still
looking for some final feedback there (see my last post) though I
would be happy to also pick a solution on my own and put it out there
for final review if that would preferable.

In the meantime, I was wondering if there were any simple tasks or
issues that would be suitable for me to attend to. Ideally they would
not be time sensitive since my availability is somewhat sparse and
sporadic.

Jonathan.

[Gregory Brown]

On 6/26/10 10:06 PM, jonsgreen wrote:

In the meantime, I was wondering if there were any simple tasks or
> issues that would be suitable for me to attend to. Ideally they would
> not be time sensitive since my availability is somewhat sparse and
> sporadic.

You could look into this image issue, my guess is it's just something
weird going on with flow or bounding boxes:

http://github.com/sandal/prawn/issues#issue/125

You can try to reproduce this bug:

http://github.com/sandal/prawn/issues#issue/102

If you can reproduce it, check the example into bugs/ and maybe write
some tests around it. You're welcome to fix it, or leave it for us to
look at later.

Once delayed rendering has been greenlighted, there will be a ton of
work to do. Had some productive time with modeling state objects while
I was out with Brad, so that will be a go, I just need to finish the
graphics code and then merge.

I'll update this thread with more things then.

-greg

[jonsgreen]

>
> You could look into this image issue, my guess is it's just something
> weird going on with flow or bounding boxes:
>
> http://github.com/sandal/prawn/issues#issue/125
>

I have confirmed that if you add a start_new_page between the images
at the end of the example then they get positioned nicely and continue
to flow down from the top of the page (This may be a simple fix for
people for now with static pages but obviously is not so helpful for
more dynamically rendered pdfs.)

However, it seems that when an image breaks at the bottom then it gets
cutoff and then the next image is pushed to the next page but the
images keep being placed at the bottom and so each successive image
keeps getting bumped to the bottom of pages.

I assume the behavior we want is that if an image is not going to fit
on the page then it should start at the top of the next page?

I am not to familiar with where in the code this automatic flow to a
new page happens but I am willing to look into it. If anyone wants to
point me in a good direction that would be great.

[jonsgreen]

Here is an idea for a simple fix that I thought I might throw out
there to see if it is worth considering (it at least corrects this
example):

def image_position(w,h,options)
options[:position] ||= :left

x = case options[:position]
when :left
...

y = case options[:vposition]
when :top
bounds.absolute_top
when :center
bounds.absolute_top - (bounds.height - h) / 2.0
when :bottom
bounds.absolute_bottom + h
when Numeric
bounds.absolute_top - options[:vposition]
else
determine_y_with_page_flow(h)
end
return [x,y]
end

def determine_y_with_page_flow(h)
if overruns_page?(h)
start_new_page
bounds.absolute_top
else
self.y
end
end

def overruns_page?(h)
(self.y - h) < bounds.absolute_bottom
end

I guess I am not sure how cool it is to call start_new_page like that.

Jonathan.

[Gregory Brown]

On Jul 3, 11:51 pm, jonsgreen <greenb...@entryway.net> wrote:
> Here is an idea for a simple fix that I thought I might throw out
> there to see if it is worth considering (it at least corrects this

Go for it for now. We'll do this in a more flexible way later when we
have a refreshed layout system.

-greg

[ct9a]

hi jonathan

last i heard from greg, he's given you the thumbsup to merge this
solution.

Any progress?
thanks

[jonsgreen]

Sorry, I usually don't get to catch up on Prawn related work until the
weekend.

Here is my fix on a local branch:
http://github.com/jonsgreen/prawn/commit/3ecde632a5b7caf41bcf742c7a221a1b1e4be86b.
I thought I would be cautious and ask for one final review before I
merge it into master.

Jonathan.

[Gregory Brown]

On Jul 11, 12:19 am, jonsgreen <greenb...@entryway.net> wrote:
> Sorry, I usually don't get to catch up on Prawn related work until the
> weekend.
>

> Here is my fix on a local branch:http://github.com/jonsgreen/prawn/commit/3ecde632a5b7caf41bcf742c7a22....

> I thought I would be cautious and ask for one final review before I
> merge it into master.

Looks good, please merge.

[Gordon Yeong]

Wow, good news :)

Please let us know when it's merged :)

[jonsgreen]

This is now merged into master.

I am not sure however whether I did this in the cleanest way since it
added some extra merge commits to the repo.

Let me know if there was a better way for me to have executed this.

Jonathan.

On Jul 12, 8:12 pm, Gordon Yeong <anexi...@gmail.com> wrote:
> Wow, good news :)
>
> Please let us know when it's merged :)
>

[jonsgreen]

I believe the extra merge commits are due to my merging of sandal-
prawn master branch periodically. I was wondering if anyone chooses to
rebase instead so that these extra merge commits don't cloud up the
commit history when merging back? Or perhaps in the end these merge
commits are not considered that deleterious? I just want to make sure
I am following standard protocol when contributing.

Also, I know Gordon Yeong at least is anxious to get this fix. How do
we decide when a new tag version is created?

If I understand correctly the suggested procedure until we start
releasing official gems is for people to clone or submodule from
github and vendor the gem themselves (http://wiki.github.com/sandal/
prawn/using-prawn-in-rails) correct?

[Brad Ediger]

On Tue, Jul 13, 2010 at 9:29 PM, jonsgreen <gree...@entryway.net> wrote:
> This is now merged into master.
>
> I am not sure however whether I did this in the cleanest way since it
> added some extra merge commits to the repo.

Merge commits are no problem. You can rebase your pulls if you want to
clean up the history (git pull --rebase sandal master), but in general
I just try to start any new feature branch from the latest master and
not worry about any merges that happen incidentally.

-be

[Gregory Brown]

On 7/15/10 4:30 AM, jonsgreen wrote:
> I believe the extra merge commits are due to my merging of sandal-
> prawn master branch periodically. I was wondering if anyone chooses to
> rebase instead so that these extra merge commits don't cloud up the
> commit history when merging back? Or perhaps in the end these merge
> commits are not considered that deleterious? I just want to make sure
> I am following standard protocol when contributing.
>
> Also, I know Gordon Yeong at least is anxious to get this fix. How do
> we decide when a new tag version is created?

This is one of the only places in which I fully retain my "benevolent
dictator" status. Releases are done when I decide to do them, roughly
according to our schedule. We've been blocking a 0.11 release on the
delayed rendering stuff, but we should get a 0.10.5 out soon with some
of these bug fixes. I will do it some time between now and the weekend.

> If I understand correctly the suggested procedure until we start
> releasing official gems is for people to clone or submodule from
> github and vendor the gem themselves (http://wiki.github.com/sandal/
> prawn/using-prawn-in-rails) correct?

This is correct, no official gems until 1.0, but using Bundler against a
tag can get you a fairly easy way to build our development gems.

-greg

[jonsgreen]

> http://github.com/sandal/prawn/issues#issue/125
>
> You can try to reproduce this bug:
>
> http://github.com/sandal/prawn/issues#issue/102
>
> If you can reproduce it, check the example into bugs/ and maybe write
> some tests around it.  You're welcome to fix it, or leave it for us to
> look at later.

I am finally getting back around to this second task.

I confirmed the bug and committed the example on a local branch:
http://github.com/jonsgreen/prawn/tree/graphic_state_issue_102.

I also pinpointed the problem in Color#set_color_space:

def set_color_space(type, color_space)
# don't set the same color space again
return if @color_space[type] == color_space
@color_space[type] = color_space
...

add_content "/#{color_space} #{operator}"
end

The @color_space has no real concept of the graphic state stack so it
does not realize that in fact the color space has changed back up the
stack to RGB after the restore.

The simple quick fix is to remove the return line but I don't know
whether there was some important purpose for that in other
applications. Otherwise one would need more intelligent tracking of
the color space.

If anyone is the lead on this part of the code let me know what they
think is the best strategy here and I can try to write specs and fix
this.

Jonathan.

[Gordon Yeong]

hi, Jon


 Good arvo.
There are two issues here.

One is http://github.com/sandal/prawn/issues#issue/125 which relates to images getting overflowed to the bottom of each page.

The other deals with the colour space. Now, if I am right, the reply you posted doesn't deal with http://github.com/sandal/prawn/issues#issue/125. Am I right?

thank you

[jonsgreen]

>  Good arvo.
> There are two issues here.
>

> One ishttp://github.com/sandal/prawn/issues#issue/125which relates to

> images getting overflowed to the bottom of each page.
>
> The other deals with the colour space. Now, if I am right, the reply you

> posted doesn't deal withhttp://github.com/sandal/prawn/issues#issue/125. Am
> I right?
>
> thank you
>
That is right. Sorry I shouldn't have copied the first line referring
to the earlier issue #125. That one was taken care of a couple weeks
ago.

[Gordon Yeong]

Cool. I thought so too. Thanks and keep up the good work, jonsgreen!

sent from my HTC desire

On 27/07/2010 7:47 AM, "jonsgreen" <gree...@entryway.net> wrote:

>  Good arvo.
> There are two issues here.
>

> One ishttp://github.com/sandal/prawn/issues#issue/125which relates to

> images getting overflowed to the bottom of each page.
>

> The other deals with the colour space. N...