MadCap Software Forums

davewilks wrote:[...] However, I cannot locate the version 9 executable. [...]

I hope you figure this one out! Mine is still in the Madcap directory in C:\Program Files and continues to function.

On my system, Flare 9 and Flare 10 are in C:\Program Files (x86)\MadCap Software

Can we use both Flare 9 and Flare 10 in the same environment? We have a team of five, and we want to have one person test 10. If that person saves in 10, will the 9 users still be able to work with the project?

helen wrote:Hmm, cute. All my note style images are tiny in Flare 10 PDF output. And my title page one. What's all that about then?

There is an option in File > Options > General tab now called "Automatically resize low DPI Images" if you uncheck this, the images should return to they way they were in V9.


Automatically resize low DPI images

Starting with Flare Version 10, images that are below 96 DPI are rendered more accurately in the XML Editor (WYSIWYG) and PDF output, usually resulting in slightly larger and more blurry images (as is consistent with their lower DPI). Previously, these images were downscaled. Therefore, if you upgrade from an older version of Flare to Version 10 or higher, you might notice images that looked a certain size before now look larger and more blurry (because their true DPI is being rendered more precisely). The best solution, and a long-term one, is to replace your lower-DPI images with higher-DPI images to be used in print output (ideally as close to 300 DPI). But you also have the option to revert back to previous version behavior..

rob hollinger wrote:

helen wrote:Hmm, cute. All my note style images are tiny in Flare 10 PDF output. And my title page one. What's all that about then?

There is an option in File > Options > General tab now called "Automatically resize low DPI Images" if you uncheck this, the images should return to they way they were in V9.


Automatically resize low DPI images

Starting with Flare Version 10, images that are below 96 DPI are rendered more accurately in the XML Editor (WYSIWYG) and PDF output, usually resulting in slightly larger and more blurry images (as is consistent with their lower DPI). Previously, these images were downscaled. Therefore, if you upgrade from an older version of Flare to Version 10 or higher, you might notice images that looked a certain size before now look larger and more blurry (because their true DPI is being rendered more precisely). The best solution, and a long-term one, is to replace your lower-DPI images with higher-DPI images to be used in print output (ideally as close to 300 DPI). But you also have the option to revert back to previous version behavior..

Interesting....although I'm not sure it's the problem I'm seeing. I changed my jpg files to gif files, I didn't change the setting you mentioned and I did not change the DPI, then they worked. Is that intended? Ie it likes one file format but not another?

We do a lot of testing with all kinds of images.
Could you please open a case with support so we can see what is going on?
https://www.madcapsoftware.com/feedback/bugs.aspx

We will need a few of the images and details on what is happening.

I did that yesterday and support are already in touch with me. They have some sample images.

Dave Lee wrote:

atomdocs wrote:I am also curious about why there has not been any fanfare. I downloaded the trial version of 10, but I could not convert it with my subscription licence key. I hope there will be some more info once the MadCap people get into the office. I haven't used 10 yet but I'm looking forward to seeing the new features.

If you're entitled to an upgrade on the maintenance plan, MadCap usually send out the new licence key by email to the person who purchased (not registered) Flare.

Mind, in my experience it's usually the day after release that I get the email.

Just discovered that the key was sent to the purchaser here yesterday, not the me, the registered user.
Glad I checked before they binned it!

Thank you Rob Hollinger - One of my Flare9 targets reproduced fine in Flare 10 except for the background image on the title page shrinking away from filling the page to a tiny little thing in the corner!

ashtontreadway wrote:Can we use both Flare 9 and Flare 10 in the same environment? We have a team of five, and we want to have one person test 10. If that person saves in 10, will the 9 users still be able to work with the project?

This is my concern as well. Appreciate any info.

Helga WHigg wrote:

ashtontreadway wrote:Can we use both Flare 9 and Flare 10 in the same environment? We have a team of five, and we want to have one person test 10. If that person saves in 10, will the 9 users still be able to work with the project?

This is my concern as well. Appreciate any info.

In the past it was not recommended or not possible, but that depends on the project. My suggestion is that one of the writers installs 10 and verifies that the projects will build as desired using a copy of the project files. I don't think mixing Flare versions is a good idea, but YMMV.

Flare V9 and V10 can be installed and run side by side.

Teams working in mixed versions.
Chances are that if a project is saved with V10, it will work in V9. For the most part, V9 simply ignores what it doesn't understand in the way of authoring.
New Features in V10 like responsive design in the skins, or native support for Perforce Source Control, or custom lists, might cause problems in V9.
As with any kind of testing between versions, it's best to keep frequent backups to avoid as little loss in production as possible.

Just upgraded to version 10.0.1. Tried to output, got this:
The Errors tab shows ID: 10083 (Buffer cannot be null. Parameter name: buffer). This occurs during the "Generating final output..." step of the build, which is pretty much the very last step. The output directory contains the output, but it's missing some crucial files. I can open the output, but it's missing a lot of resources. Images missing, wrong skin, and a few other quirks.

The output was successful with 10.0, so something happened with the 10.0.1 update.

I've notified MadCap, will report as I investigate.

UPDATE (3-7-14): Issue only occurs with one of my Targets, which is linked to a unique Skin. Need to determine now whether it's the Target or Skin.

techwriterkai wrote:A couple of unexpected insights about Flare 10:

Apply character styles to text inside a table
Previously, you couldn’t apply character styles to the complete text inside a table cell, but you had to add a space at the end and then style the rest of the text. This is allegedly fixed, but in my installation the fix appears with a new bug. Yes, you can now style text in a table cell, but doing so will give you two blinking cursors with split focus, so you can move the cursor, select and delete text in one place and type in the other place. It’s a mess that renders the XML Editor unusable until you close and re-open Flare 10. I’ve reported the new bug.

This has been fixed by the Flare 10.0.1 update on 6 March. Or you can fix it by ensuring you run .NET Framework 4.5.1 as per Flare 10's system requirements.

Mad props for MadCap for fixing this 2 days after the release!

I tried out MadCap Flare 10 with some Page Layouts that I'd created in Version 9, and it did not render the resulting PDF as it had done in Version 9 - graphics and footers had changed size and alignment. So, if you're still having to cater for end users who want PDFs, I would definitely proceed with caution.

For now, I'm sticking with Version 9.

Is anyone able to import from FrameMaker into Flare 9 after installing Flare 10? I'm running into issues. Please see my post here:
http://forums.madcapsoftware.com/viewto ... =5&t=18508

RamonS wrote:Interesting....those associated with the beta program apparently are told last. I'll keep the rest of my intended comment to myself....

I was quite surprise as well. In fact, I felt kind of slapped (I got over it quickly) b/c I was testing the beta less than 24 hours before MadCap announced its GA. Kind of wasted my time... but not really... after all, I was discovering the new features as well.

Believe me, MadCap is not unique with rather poor beta user communications. The Adobe Captivate team is never in the loop about release dates and they are always the last to know. Overall, the Flare beta experience was the least organized beta I participated in.... I was expecting defined tasks and a beta of the user guide to accompany the testing.

johnnygreen wrote:I tried out MadCap Flare 10 with some Page Layouts that I'd created in Version 9, and it did not render the resulting PDF as it had done in Version 9 - graphics and footers had changed size and alignment. So, if you're still having to cater for end users who want PDFs, I would definitely proceed with caution.

For now, I'm sticking with Version 9.

Odd, I have some rather complex page layouts and I experienced absolutely no difficulties/changes in v10.

FYI, there is a Madcap webinar next week, "What’s New in MadCap Flare 10: An Overview". This might prove valuable to many.

Description:
This one hour webinar will provide an overview of the new functionality and capabilities that have been added to MadCap Flare. Learn what's new in MadCap Flare Version 10, including responsive HTML5 output, built-in project templates, a modern real-time HTML5 skin editor and much more.

Register [for free] here:
http://www.madcapsoftware.com/resources ... inars.aspx

Ineffable wrote:Just upgraded to version 10.0.1. Tried to output, got this:

error.jpg

The Errors tab shows ID: 10083 (Buffer cannot be null. Parameter name: buffer). This occurs during the "Generating final output..." step of the build, which is pretty much the very last step. The output directory contains the output, but it's missing some crucial files. I can open the output, but it's missing a lot of resources. Images missing, wrong skin, and a few other quirks.

The output was successful with 10.0, so something happened with the 10.0.1 update.

I've notified MadCap, will report as I investigate.

UPDATE (3-7-14): Issue only occurs with one of my Targets, which is linked to a unique Skin. Need to determine now whether it's the Target or Skin.

Check the Skin.
Look for images set to none.

Check this out. In my footer, we have a condition set for "Confidential" and "Internal Use" documents for the print output. They want this to be red. The page layout has a regular table where I set the color inline. It doesn't matter how I do it, the last color of that character will follow after a page break until the next style:
Now this originally started with Flare 8, but the fix was relatively easy. I just set the color for every CSS item:
What's different in Flare 10? If there is a CSS item that has a page break in the middle, it will use the last color used in the footer until the next class reset. This is causing a big problem with list items and tables:
So, what happens if I place a period after that inline SPAN? I get this:
What happens if that period is white? I get this:
Here is my footer frame in the page layout:
I have tried to use a plain period and hide it in the page layout with HTML code. It doesn't work. I have tried to make a hidden DIV, SPAN, and P class in the CSS. Same result. Someone messaged me today saying the <tr> custom settings in the table stylesheets are not working either. We told everyone to NOT to uninstall Flare 9, and to use 9 if they have issues, until we can straighten this stuff out. Totally didn't expect this to happen. The last version updates went pretty flawless.

I can say online outputs run better. I give it that so far.

rob hollinger wrote:

Ineffable wrote:Just upgraded to version 10.0.1. Tried to output, got this:

error.jpg

The Errors tab shows ID: 10083 (Buffer cannot be null. Parameter name: buffer). This occurs during the "Generating final output..." step of the build, which is pretty much the very last step. The output directory contains the output, but it's missing some crucial files. I can open the output, but it's missing a lot of resources. Images missing, wrong skin, and a few other quirks.

The output was successful with 10.0, so something happened with the 10.0.1 update.

I've notified MadCap, will report as I investigate.

UPDATE (3-7-14): Issue only occurs with one of my Targets, which is linked to a unique Skin. Need to determine now whether it's the Target or Skin.

Check the Skin.
Look for images set to none.

Yep, that's what I found. However, there must be a bug or something else going on because I am not able to add any newer images other than the ones that are already shown within the skin in the image browser that is summoned from the tablet/mobile skin editor. If I browse to a new image and try to add it, for some reason it doesn't stick; the same images are always shown. When I select none--since none of the images are usable--I get this error.

qtxasjo wrote:I installed it this morning and so far not so good. I have a coloured table heading (blue) and the first cell of each table heading is now black in my output. Also, conditional text that shouldn't be displayed (and wasn't yesterday) is now visible in the output.

Is there somewhere I can read a complete list of the changes made in Flare 10?

EDIT: Ok, I have done some troubleshooting now. It seems that the first cell of the table heading is black if the table comes directly after a heading or an image. If the table comes after body text or a numbered list, all is well.

Now I'll see why the conditional text is displayed in the output even though it is set to be excluded...

Has anyone else had this problem? I have this problem, as well, in my tables. The heading is blue, and now the first cell in the next row is also blue in my output. However, this is happening even to tables that are after body text (not directly after a heading or an image).

It is very frustrating as I cannot release my tables looking like this, but there doesn't seem to be a fix either.

I've solved the problem of the resized images, with a little help from Rob Hollinger's posting - you untick 'Tools > Options > Automatically resize low DPI images' . However, in my opinion, that should never have been set as default. It was bound to throw a lot of people.

johnnygreen wrote:I've solved the problem of the resized images, with a little help from Rob Hollinger's posting - you untick 'Tools > Options > Automatically resize low DPI images' . However, in my opinion, that should never have been set as default. It was bound to throw a lot of people.

Agreed! It got me too, in the early days.

Time to make a feature request: https://www.madcapsoftware.com/feedback ... quest.aspx