Thanks Walter. Unfortunately, I wasted nearly half a day trying to figure that out. Thankfully, another member saved me from investing any more time. Perhaps we should make a list of known bugs and post it on this forum?
On 12 Jun 2012, 3:12 pm, waltd wrote:
It’s a design-view visual feedback bug, as you noted. Softpress have never once promised a delivery time for a bug fix, and I wouldn’t expect them to start now. If you can train your eyes to ignore this for now, you will be pleased not to have to do it forever when they do figure out a way to get around it. Click over to preview, note how it will render in a browser, then get back to your layout.
Do you have a line-height in your body? If so remove it from there and add it to the p, H or whatever it should go to. The line-height in the body forces the construction divs to behave as they do. That’s the bug as far as I remember from that screencast related list.
Freeway Pro sometimes inserts paragraph (p) tags into html div boxes which
are “empty”. If line-height in the body tag is affecting container divs
whose only contents are inline html boxes, then it may be because of that.
Check for it in the code, if it’s there you can use Tim Plumb’s Remove
Paragraph Tags on the empty wrapping div to fix that.
–
Ernie Simpson
On Tue, Jun 12, 2012 at 12:30 PM, Thomas Kimmich email@hidden wrote:
Do you have a line-height in your body? If so remove it from there and add
it to the p, H or whatever it should go to. The line-height in the body
forces the construction divs to behave as they do. That’s the bug as far as
I remember from that screencast related list.
Do you have a line-height in your body? If so remove it from there and add it to the p, H or whatever it should go to. The line-height in the body forces the construction divs to behave as they do. That’s the bug as far as I remember from that screencast related list.
Freeway Pro sometimes inserts paragraph (p) tags into html div boxes which
are “empty”. If line-height in the body tag is affecting container divs
whose only contents are inline html boxes, then it may be because of that.
Check for it in the code, if it’s there you can use Tim Plumb’s Remove
Paragraph Tags on the empty wrapping div to fix that.
Are these items that you are inserting as inline elements HTML items, passthrough graphics or graphic items? I ask because Freeway will wrap graphic items in a parent paragraph tag which I suspect is what you are seeing. To get around this either make sure that all floated items are HTML (and nest the graphic items within these) or adjust the default paragraph spacing to virtually illuminate the issue as I think Thomas suggested.
Regards,
Tim.
You have a couple of threads these days with “inline” specific questions. One of them had been something about styles, body-tag, paragraph and all this fancy stuff.
One of the answers had been, that you can create a body style and add some “basic” settings such as font-family or line-height…
This is absolutely brillant except the fact, that regular inserted divs in div are reacting on that line-height added to the body style and showing then that stairs we are talking about.
So all I asked is:
Do you have within your styles one called body and if, is there is a line-height and if, remove it to see if this fixes it. I never ever had any problems with it (as shown in the screencast) except the above described.
I gotcha. Sorry for the misunderstanding Thomas. Yes, I have a body style that was applied to the HTML box. I removed that and all the boxes lined up, so I’m good to go.
However, I guess this means I’ll have to style the text in each of the inline boxes at the item level, not the container or page level, correct?
I don’t understand where this uneven “stairs” effect is coming from. I took
time to make a couple inline layouts as has been described without any
anomaly in appearance in any mode of view. The only way they don’t line up
is if they are all set to clear instead of none. I am using FWP 5.6.4.
(6412)
–
Ernie Simpson
On Tue, Jun 12, 2012 at 3:29 PM, Thomas Kimmich email@hidden wrote:
You have a couple of threads these days with “inline” specific questions.
One of them had been something about styles, body-tag, paragraph and all
this fancy stuff.
One of the answers had been, that you can create a body style and add some
“basic” settings such as font-family or line-height…
This is absolutely brillant except the fact, that regular inserted divs in
div are reacting on that line-height added to the body style and showing
then that stairs we are talking about.
So all I asked is:
Do you have within your styles one called body and if, is there is a
line-height and if, remove it to see if this fixes it. I never ever had any
problems with it (as shown in the screencast) except the above described.
As an aside, be aware that there’s a difference between “.body” which is a class-level style named “body” and the actual body tag which can also be targeted for styling.
Todd
On Jun 12, 2012, at 9:14 PM, RavenManiac wrote:
Hey Ernie, here are the specifics of my .body style.
Todd is right, and if your “body” style is a class level style (the name
‘body’ would appear in the Name field of the Style Editor and NOT the Tag
field then it isn’t automatic - it must be applied to something, and I
would have to wonder to what??
I wish there was an easier way for all of us to get on the same page,
especially with the language of what is really what. It’s confusing
–
Ernie Simpson
On Tue, Jun 12, 2012 at 10:21 PM, Todd email@hidden wrote:
As an aside, be aware that there’s a difference between “.body” which is a
class-level style named “body” and the actual body tag which can
also be targeted for styling.
Todd
On Jun 12, 2012, at 9:14 PM, RavenManiac wrote:
Hey Ernie, here are the specifics of my .body style.
As Ernie I tried to reproduce but “suddenly, nothing happened :-)”. So convinced (… til these days) I recorded that time this “inline stuff screener” to show that there is nothing abnormal.
But believe me or not. Only 5 minutes after publishing the screencast (happy that nothing happened) I played a bit further with that doc and you know what? I produced stairs. Why??? I don’t have an answer but I found an odd screenshot:
Ernie, I’ve also found it impossible to reproduce this stepping behaviour unless I insert a graphic item. I pointed out before on a previous thread (http://www.freewaytalk.net/thread/view/91022#m_91237) that graphic items are wrapped in paragraph tags which is why, unlike HTML items, Freeway steps the content. If you set View > Invisibles then you should be able to see any hidden paragraph tags within the document.
To compound this Freeway appears to have a slight issue when moving graphic items in an in-flow environment in that it appears to create unneeded paragraph tags as the item is moved.
The Remove Paragraph Tags Action works on the final generated page code (behind Freeway’s back) so will remove the unwanted items when previewed or published but sadly can’t alter the design view.
Kelly, If you have a stripped down Freeway document that you can post as an example then I’m sure several of us can jump on it and see what the issues are and how best to resolve them.
Thanks,
Tim.
If you alter the line-height (leading) attribute in the body tag style, the
“staircasing” follows it. Somehow FWP is forcing the appearance of each
html div item to start on the next baseline as if it were a new line of
text. This is odd as the divs are not wrapped in text – at least not in the
output. Clearly this is just something which affects FWP’s imagination as
it draws the page. Setting the vertical-align attribute, either on the body
tag style or inline on the images is ignored by FWP in the layout view.
IS THERE ANYBODY WHO FEELS THE INLINE DRAG FEATURE IS WORTH KEEPING?
–
Ernie Simpson
On Wed, Jun 13, 2012 at 10:55 AM, Tim Plumb email@hidden wrote:
I’d still like to see that document at some point if you can share and
example Freeway file.
Regards,
Tim.
On 13 Jun 2012, at 14:44, RavenManiac wrote:
Hey Tim, I removed the .body style from the container box that was
wrapping the inline boxes and I’m good to go. N stair stepping.
A thousand times no. This has tripped me and my clients more times than I can count. Drag move text, sure, but inline objects are not text and should not re-order when dragged.
Walter
On Jun 13, 2012, at 11:43 AM, Ernie Simpson wrote:
IS THERE ANYBODY WHO FEELS THE INLINE DRAG FEATURE IS WORTH KEEPING?
