Among the other settings for the PDF report, there’s an option to insert project name and/or report file name into report header or footer by the use of those handy tiny buttons on the Header/Footer tab. But these fields aren’t visible in the resulting pdf file unless they are ANSI compatible.
The reason is that BP-VA utilizes non-embedded ANSI-encoded Helvetica font for these fields instead of the embedded custom-encoded subset that is used for all the rest.
And the “Selection Font” button (with “T” caption) isn’t of any help here, because it doesn’t provide encoding option.
Thanks for your post. I’ve forwarded the details to our engineers for further investigation. Once there is any feedback, I’ll come back to you immediately.
Just to remind you that when you generate PDF report:
select the appropriate encoding (please refer to pdf_report_encoding.png)
under Header/Footer tab, click Selection Font and select “(Default)”, which is associated with the encoding you choose in step 1 (please refer to selection_font.png). This step need to be done for each section block of header/footer.
If there are any further inquiries, please feel free to contact me again.
I confirm that the problem is fixed.
Thank you very much.
OTOH, it must be admitted that the usability of this feature is suboptimal for the time being. Firstly, it forces the user to do an excess work (why the “(Default)” isn’t defaulted?). Secondly, inserted field is displayed in the dialog window as an image, and therefore isn’t highlihted when the user selects it. (Wouldn’t it be handier to display it in the &[…] form?)
Thanks for replying and it’s a good news that the problem has been fixed.
For the issue of manual selection of (Default), I’ve forwarded to our engineers to follow up. I’ll inform you immediately for any news about this.
On the other hand, when you add an image to the fields under Header/Footer tab, then will be an clickable icon added into the field. If you click on the icon, you will be able to locate another image to replace the original one. The design of showing clickable icon is to provide an handier way to change image.
If you have any inquiries, please feel free to contact me again.
Thank you for your reply. Indeed, it would be quite logical and consistent to have “(Default)” as an actual default.
Meanwhile, I found a way to achieve what I’ve sought after: I edited the .vp.preference file manually and changed “Helvetica” to “(Default)” in the “” tag and in similar tags. Furthermore, I added some text into the “” and similar tags, and now all my new projects have pre-filled report headers and footers.
The standard layout of the reports is one of the requirements in the enterprise environment. Now, if only there was a “standard” way to pre-create the preference file and propagate it between workplaces… But oh well…
As for the second part of your post:
On the other hand, when you add an image to the fields under Header/Footer tab, then will be an clickable icon added into the field.
If you click on the icon, you will be able to locate another image to replace the original one.
Sorry, I don’t get it. When I click on the icon in Header/Footer tab, the corresponding field is inserted at the cursor position. This field is displayed as exactly the same icon as the button pressed, but this inserted icon isn’t clickable, of course. Now, in order to change the font I must select the newly inserted “icon” by dragging the mouse over it and then press the “Selection Font” button, right? But dragging the mouse over an image doesn’t highlight that image. That’s what I’ve meant.
Thanks for your details and I’m sorry that I misunderstood your meaning about “image” before. I’ve forwarded your details to our engineers to follow-up. I’ll come back to you immediately if there is any news on the issue.
FYI, our engineers are fixing the default encoding issue for PDF report. I’ll notify you when it’s fixed.
If you have any inquiries, please do not hesitate to contact me.
The font setting in “Selection Font” will apply to the entire block, i.e. the font setting will apply to all the fields you inserted, so you do not need to select any icons inside the block. Could this solve your problem?
I can’t disagree more. The problem we are talking about is just visual inconvenience – the user got accustomed to see a highlight when she selects a part of text, and here (e.g. while selecting the inserted project name field) the selection won’t be highlighted. That’s slight usability question, no more.
But the approach you’re speaking of is (IMHO) change for the worse. It would be totally counter-intuitive. All font modifications should be applied to the (explicitly and intentionally) selected part of text, in accordance with the regular dedication and behaviour of “Selection Font” button.
Nad
P.S. Setting aside the “selection problem”, I hope that your developers will agree to set the default font for header/footer fields as “(Default)” instead of Helvetica.
Thanks for your reply and I’m sorry for my misunderstanding.
Would you mind clarifying the behavior you expected in more details? It would be appreciated for any suggestion so that we can consider the possibility to support what you expected. Thanks in advance!
FYI, our engineers are fixing the default font setting for Header/Footer. After fixed, it will be (Default) instead of Helvetica when you select the encoding other than “English”. Once the problem is fixed, I’ll come back to you at once.
Sorry, I didn’t noticed right away that the behavior of the “Selection Font” button has actually changed in the latest patch. Formerly this button wasn’t activated until the user has selected the part of text she wanted to change the font for. Currently this button works independent of selection, and font settings are enforced for the whole header/footer block. That’s OK with me, but the hint for the button should be properly rephrased, e.g. “Change Font for the block at cursor”.
Having failed to notice this change of behavior, I talked about usability of previously implemented font setting functionality, when the user could change the font for just the selected part of text. It’s no doubt that “old” functionality has been much more common than the current one, and I can’t judge whether or not this choice of your developers is justifiable.
Thanks for your details and the suggestions. I’ve forwarded your suggestions to our engineering to consider. If there is any feedback, I’ll notify to you at once.
If there are any inquiries, please feel free to contact me again.
