I've was working with gradient fills the other day, and noticed that there is only one iteration done in the fill style. is there an option tucked away somewhere, that will give more iterations of the fill style?

[Non-text portions of this message have been removed]

I'm not quite sure what you mean be "one iteration".

Tim Doty

On Dec 1, 2012, at 8:02 PM, admfubar@gmail.com wrote:

> I've was working with gradient fills the other day, and noticed that there is only one iteration done in the fill style. is there an option tucked away somewhere, that will give more iterations of the fill style?
>
> [Non-text portions of this message have been removed]
>
>

The gradient fill only does one transition between the colors selected. I'd like to see an option for selecting the number of times the transition is done.

On Sat, 01 Dec 2012 21:14:42 -0500, Tim Doty <thoromyr@mac.com> wrote:

> I'm not quite sure what you mean be "one iteration".
>
> Tim Doty
>
> On Dec 1, 2012, at 8:02 PM, admfubar@gmail.com wrote:
>
>> I've was working with gradient fills the other day, and noticed that there is only one iteration done in the fill style. is there an option tucked away somewhere, that will give more iterations of the fill style?
>>
>> [Non-text portions of this message have been removed]
>>
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Ah, okay. To my knowledge there is no way of doing this directly within PgS. For example, the scripting documentation covers the number of colors assigned and notes that exceeding two is a possibility for the future*. Sounds like a reasonable feature request, though.

http://www.pagestream.org/?action=Documents&id=511

Tim Doty

On Dec 1, 2012, at 8:19 PM, admfubar@gmail.com wrote:

> The gradient fill only does one transition between the colors selected. I'd like to see an option for selecting the number of times the transition is done.
>
> On Sat, 01 Dec 2012 21:14:42 -0500, Tim Doty <thoromyr@mac.com> wrote:
>
> > I'm not quite sure what you mean be "one iteration".
> >
> > Tim Doty
> >
> > On Dec 1, 2012, at 8:02 PM, admfubar@gmail.com wrote:
> >
> >> I've was working with gradient fills the other day, and noticed that there is only one iteration done in the fill style. is there an option tucked away somewhere, that will give more iterations of the fill style?
> >>
> >> [Non-text portions of this message have been removed]
> >>
> >>
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>

On Sat, 01 Dec 2012 21:27:42 -0500, Tim Doty <thoromyr@mac.com> wrote:

> Ah, okay. To my knowledge there is no way of doing this directly within PgS. For example, the scripting documentation covers the number of colors assigned and notes that exceeding two is a possibility for the future*. Sounds like a reasonable feature request, though.

time for the future to be now!, i'm all for this to be an addition.

my inspiration for this is an image on this page, the soup contest. i liked that there were several iterations of the color change in the gold looking panel on the left.

http://www.otbbicyclecafe.com/?p=1035

Exporting to .html strips hyphens.

eg "self-serving" becomes "selfserving"

Is this a bug, a 'feature' or am I doing something wrong?

regards, Jim

Always trying to do things that original could not be done (easily):

You could break that (yellow soup contest rectangle) up in many as
needed segments and filling each segment with the two colors you need.
Be sure to end the one segment and the start of the next segment with
the same color (and use the same angle).
OK, it's a lot work.

I need that feature also.
But than again, there are a lot of things I need: a better FX
(http://www.pagestream.org/?action=Documents&id=831), now adjustable.
Also afterwards.
PGS shrinks bitmaps when saved to PDF.
Not all fills show up in PDF's.

Theo - inspiring Deron? Still doing a lot of work with PGS! Wouldn't
want to miss it!

Op 2-12-2012 4:25, admfubar@gmail.com schreef:
> On Sat, 01 Dec 2012 21:27:42 -0500, Tim Doty <thoromyr@mac.com> wrote:
>
>> Ah, okay. To my knowledge there is no way of doing this directly within PgS. For example, the scripting documentation covers the number of colors assigned and notes that exceeding two is a possibility for the future*. Sounds like a reasonable feature request, though.
> time for the future to be now!, i'm all for this to be an addition.
>
> my inspiration for this is an image on this page, the soup contest. i liked that there were several iterations of the color change in the gold looking panel on the left.
>
>http://www.otbbicyclecafe.com/?p=1035
>
>
>

--
PageStream Pro 5.0.5.8 on Windows 7 Pro 64 bits (Dutch), Python 2.7.3 and PySide 1.1.1 (all 32 bits, unless stated otherwise)
AMD Athlon(tm) II X2 215 Processor at 2.70 GHz and 4 GB RAM

I would think that to be a bug. Just two questions:

1. How have you determined that the character is disappearing? Does it not show up in a web browser? Have you looked at the file with a text editor? If PgS is exporting the dash as an entity but not doing so in a way that the web browser likes it wouldn't show up.

2. What character is it that is disappearing? is that a dash character? A true hyphen? A soft hyphen? Because I can easily see PgS behaving differently in each case.

With a soft hyphen omitting them during export would be correct, but in the other cases they should be retained.

With a true hyphen it might be omitted due to a complication of character encoding.

If a dash character is omitted on export that would be, I would expect, a different sort of bug.

Tim Doty

On Dec 2, 2012, at 12:48 AM, video@got.net wrote:

> Exporting to .html strips hyphens.
>
> eg "self-serving" becomes "selfserving"
>
> Is this a bug, a 'feature' or am I doing something wrong?
>
> regards, Jim
>

Hi Theo,

What do you mean "PGS shrinks bitmaps when saved to PDF"? If I tell it to use a max dpi for the bitmaps it does so. Whether or not I do this the images show up the correct size.

At least, that has been the case on documents I've worked with.

As for the fills not showing up in PDFs -- agreed. The work around is to export the graphic as a bitmap, replace the vector and then export. Ugly. IMO a reasonable feature in PgS would be to automatically do that for the specified dpi when encountering fills that it can't produce in PDF with vectors. Even better would be to find a way to produced them, of course, but still it would be a nice improvement.

Another thing has to do with TextFX. If you have an outlined text where characters overlap (say, a script font) then the outline is not continuous in the text. The work around is to convert to path, split paths, deselect interior paths, do a path union, reselect all interior paths, do an XOR or subtract. Such an operation is prone to errors (I missed deselecting an interior path the last time). It isn't clear to me what would be the best way to handle this programmatically. If it is reasonable to determine interior paths programmatically ( I would *think* so) then simply following the manual steps in a single function available from the GUI would be handy. But even better would be doing the operation on export or print so that the text could be retained as editable text.

Tim Doty

On Dec 2, 2012, at 2:14 AM, Theo Zweers <tjzwrs@gmail.com> wrote:

> Always trying to do things that original could not be done (easily):
>
> You could break that (yellow soup contest rectangle) up in many as
> needed segments and filling each segment with the two colors you need.
> Be sure to end the one segment and the start of the next segment with
> the same color (and use the same angle).
> OK, it's a lot work.
>
> I need that feature also.
> But than again, there are a lot of things I need: a better FX
> (http://www.pagestream.org/?action=Documents&id=831), now adjustable.
> Also afterwards.
> PGS shrinks bitmaps when saved to PDF.
> Not all fills show up in PDF's.
>
> Theo - inspiring Deron? Still doing a lot of work with PGS! Wouldn't
> want to miss it!
>
> Op 2-12-2012 4:25, admfubar@gmail.com schreef:
> > On Sat, 01 Dec 2012 21:27:42 -0500, Tim Doty <thoromyr@mac.com> wrote:
> >
> >> Ah, okay. To my knowledge there is no way of doing this directly within PgS. For example, the scripting documentation covers the number of colors assigned and notes that exceeding two is a possibility for the future*. Sounds like a reasonable feature request, though.
> > time for the future to be now!, i'm all for this to be an addition.
> >
> > my inspiration for this is an image on this page, the soup contest. i liked that there were several iterations of the color change in the gold looking panel on the left.
> >
> >http://www.otbbicyclecafe.com/?p=1035
> >
> >
> >
>
> --
> PageStream Pro 5.0.5.8 on Windows 7 Pro 64 bits (Dutch), Python 2.7.3 and PySide 1.1.1 (all 32 bits, unless stated otherwise)
> AMD Athlon(tm) II X2 215 Processor at 2.70 GHz and 4 GB RAM
>
>

On Sun Dec 2 06:20:20 2012, Tim Doty <thoromyr@mac.com> wrote:

Hi, Tim ...

> I would think that to be a bug. Just two questions:
>
> 1. How have you determined that the character is disappearing? Does
> it not show up in a web browser? Have you looked at the file with a
> text editor? If PgS is exporting the dash as an entity but not doing
> so in a way that the web browser likes it wouldn't show up.

Yeah; did a bit of sleuthing on a test file.

.PGS file contains a hard hyphen/dash/minus (ASCII 45 dec), but the
.htm output translates that into a soft hyphen (&shy)

> With a soft hyphen omitting them during export would be correct, but
> in the other cases they should be retained.

Yup.

> With a true hyphen it might be omitted due to a complication of
> character encoding.
>
> If a dash character is omitted on export that would be, I would
> expect, a different sort of bug.

My conclusion as well; I was just wondering whether there was some
option I had missed regarding handling of hyphens. My short-term
workaround is to search/replace all the hyphens with = or + or some
such char that is not otherwise used in the text and then do the
same in reverse to recover the hyphens. This is a 350 page book
being converted to .mobi (kindle). Not a terribly easy task, it
turns out. The best results have been .htm from PageStream, converted
to .odt with AVS text converter, cleanup in LibreOffice, then convert
to .mobi in Calibre. Other than the hyphen anomaly, the result is
perfect - but time-consuming. And I have two more books yet to
convert :^)

Tnx for the thoughts.

regards, Jim

Hmmm… given that it is the ASCII dash in the PgS file I would call it a bug that it is exported as a soft hyphen character entity. That should be an easy fix for Deron, I would think.

Another option for you (rather than the 'to another character and back again') might be to convert to an actual hyphen (ctrl-d, 2010). The html export keeps that as a character entity (&#2010;) so if the other end has the hyphen it would work. Unfortunately, even Times Roman lacks a glyph for that code point so I'm not sure how common support is...

On Dec 3, 2012, at 2:03 AM, video@got.net wrote:

> On Sun Dec 2 06:20:20 2012, Tim Doty <thoromyr@mac.com> wrote:
>
> Hi, Tim ...
>
> > I would think that to be a bug. Just two questions:
> >
> > 1. How have you determined that the character is disappearing? Does
> > it not show up in a web browser? Have you looked at the file with a
> > text editor? If PgS is exporting the dash as an entity but not doing
> > so in a way that the web browser likes it wouldn't show up.
>
> Yeah; did a bit of sleuthing on a test file.
>
> .PGS file contains a hard hyphen/dash/minus (ASCII 45 dec), but the
> .htm output translates that into a soft hyphen (&shy)
>
> > With a soft hyphen omitting them during export would be correct, but
> > in the other cases they should be retained.
>
> Yup.
>
> > With a true hyphen it might be omitted due to a complication of
> > character encoding.
> >
> > If a dash character is omitted on export that would be, I would
> > expect, a different sort of bug.
>
> My conclusion as well; I was just wondering whether there was some
> option I had missed regarding handling of hyphens. My short-term
> workaround is to search/replace all the hyphens with = or + or some
> such char that is not otherwise used in the text and then do the
> same in reverse to recover the hyphens. This is a 350 page book
> being converted to .mobi (kindle). Not a terribly easy task, it
> turns out. The best results have been .htm from PageStream, converted
> to .odt with AVS text converter, cleanup in LibreOffice, then convert
> to .mobi in Calibre. Other than the hyphen anomaly, the result is
> perfect - but time-consuming. And I have two more books yet to
> convert :^)
>
> Tnx for the thoughts.
>
> regards, Jim
>
>