When I create a new doc under Win7 x64-bit the .xht is proposed. I was thinking the default would be .html as described in some post.
How this format can be managed whatever BG can read by default a lot of different format/encoding?
For me the saving info must at least be in accordance with the suffix. The managing of the encoding can also be a problem as the UTF-8 encoding is not updated in accordance with the file saving format.
In fact that not solving to create a file with the UTF-8 encoding. The file is created in ANSI format with UTF-8 character inside well manage when displayed by IE9 at least.
Many Thanks Greg,
I was shy to use more than the File -> New
In fact that not solving to create a file with the UTF-8 encoding. The file
is created in ANSI format with UTF-8 character inside well manage when
displayed by IE9 at least.
Jpm
-----Message d'origine-----
De : bluegriffon@googlegroups.com [mailto:bluegriffon@googlegroups.com] De
la part de Greg Chapman
Envoyé : mardi 16 octobre 2012 10:59
À : bluegriffon@googlegroups.com
Objet : Re: [BlueGriffon] .xht or .html
Hi jpm,
On 16 Oct 12 09:40 jpm <jpaul.mesn...@gmail.com> said:
> When I create a new doc under Win7 x64-bit the .xht is proposed.
> I was thinking the default would be .html as described in some post.
When creating a new document use either:
# File > New Wizard
# The drop-down on the New Document toolbar button and select: More options.
# CTRL-SHIFT-N
The options you select through those dialogues will become the default for
new douments thereafter.
--
You received this message because you are subscribed to the Google Groups
"bluegriffon" group.
To post to this group, send email to bluegriffon@googlegroups.com To
unsubscribe from this group, send email to
bluegriffon+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/bluegriffon?hl=en
On 16 Oct 12 11:08 "J-Paul Mesnage" <jpaul.mesn...@gmail.com> said:
> In fact that not solving to create a file with the UTF-8 encoding. > The file is created in ANSI format with UTF-8 character inside well > manage when displayed by IE9 at least.
Apologies. It seems that I lied. Having checked, I find that while some options on the new document dialogues do appear to become the default thereafter, the character set is not fixed.
I now believe you need to use the configuration editor (Tools > Preferences > Advanced > Configuration Editor > I'll be Careful, I Promise) to permanently adjust the initial character set.
Once in the editor search for the setting:
intl.charset.default
and change that to "utf-8" (without the quotes).
CAUTION: I do not regard myself as an expert. It is possible there are
effects that I am unaware of when adjusting this option.
> Apologies. It seems that I lied. Having checked, I find that while > some options on the new document dialogues do appear to become the > default thereafter, the character set is not fixed. I now believe you > need to use the configuration editor (Tools > Preferences > Advanced > > Configuration Editor > I'll be Careful, I Promise) to permanently > adjust the initial character set. Once in the editor search for the > setting: intl.charset.default and change that to "utf-8" (without the > quotes). CAUTION: I do not regard myself as an expert. It is possible > there are effects that I am unaware of when adjusting this option. > Greg Chapman http://www.gregtutor.plus.com Helping new users of > KompoZer and The GIMP Still exploring BlueGriffon
Hi Greg.
I was hoping this would help me as well but it hasn't. I recently created an extra page on my site and, when saving it, it insists on trying to save it as .xht instead of .html. I have to manually change the file extension each time.
All the other pages are fine. Do you have any idea how to get this one page to use .html as the default when saving, please?
On 19 Oct 12 10:41 Howard Neil <h.n...@which.net> said:
> I was hoping this would help me as well but it hasn't. I recently > created an extra page on my site and, when saving it, it insists on > trying to save it as .xht instead of .html. I have to manually > change the file extension each time.
As I understand it, BlueGriffon will save with an .xht file extension when a file has an XHTML doctype. So I suspect that's how your extra page was created. If that's the case then...
> All the other pages are fine. Do you have any idea how to get this > one page to use .html as the default when saving, please?
Open one of your other pages, which I assume will be of an HTML4 doctype, switch to source view and copy the DOCTYPE line there, then switch to your extra page and paste over its doctype line with the one
you've copied.
As you switch out of source view, BlueGriffon will re-parse the page converting all XHTML tags to HTML tags, and will in future save with a
.html extension.
I di dit but it does seem to work.
Still .xht proposed and the file is created in ANSI format
I hope Daniel can have a better answer.
It seems we really new Preferences options to handle such file creation.
Thanks again for your help
J-Paul
-----Message d'origine-----
De : bluegriffon@googlegroups.com [mailto:bluegriffon@googlegroups.com] De
la part de Greg Chapman
Envoyé : vendredi 19 octobre 2012 10:35
À : bluegriffon@googlegroups.com
Objet : Re: [BlueGriffon] .xht or .html
Hi J-Paul,
On 16 Oct 12 11:08 "J-Paul Mesnage" <jpaul.mesn...@gmail.com> said:
> In fact that not solving to create a file with the UTF-8 encoding. > The file is created in ANSI format with UTF-8 character inside well > manage when displayed by IE9 at least.
Apologies. It seems that I lied. Having checked, I find that while some
options on the new document dialogues do appear to become the default
thereafter, the character set is not fixed.
I now believe you need to use the configuration editor (Tools > Preferences
> Advanced > Configuration Editor > I'll be Careful, I
Promise) to permanently adjust the initial character set.
Once in the editor search for the setting:
intl.charset.default
and change that to "utf-8" (without the quotes).
CAUTION: I do not regard myself as an expert. It is possible there are
effects that I am unaware of when adjusting this option.
--
You received this message because you are subscribed to the Google Groups
"bluegriffon" group.
To post to this group, send email to bluegriffon@googlegroups.com To
unsubscribe from this group, send email to
bluegriffon+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/bluegriffon?hl=en
> On 19 Oct 12 10:41 Howard Neil <h.n...@which.net> said:
>> I was hoping this would help me as well but it hasn't. I recently
>> created an extra page on my site and, when saving it, it insists on
>> trying to save it as .xht instead of .html. I have to manually
>> change the file extension each time.
> As I understand it, BlueGriffon will save with an .xht file extension
> when a file has an XHTML doctype. So I suspect that's how your extra
> page was created. If that's the case then...
>> All the other pages are fine. Do you have any idea how to get this
>> one page to use .html as the default when saving, please?
> Open one of your other pages, which I assume will be of an HTML4
> doctype, switch to source view and copy the DOCTYPE line there, then
> switch to your extra page and paste over its doctype line with the one
> you've copied.
> As you switch out of source view, BlueGriffon will re-parse the page
> converting all XHTML tags to HTML tags, and will in future save with a
> .html extension.
> Greg Chapman
> http://www.gregtutor.plus.com > Helping new users of KompoZer and The GIMP
> Still exploring BlueGriffon
Hi Greg,
Thanks for the suggestion. Unfortunately, there is a problem. The code returns a Parsing Error when pasted into the problem page. Any ideas, please? the line I have copied and tried to paste is:-
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> On 19/10/2012 11:44, Greg Chapman wrote:
>> Hi Howard,
>> On 19 Oct 12 10:41 Howard Neil <h.n...@which.net> said:
>>> I was hoping this would help me as well but it hasn't. I recently
>>> created an extra page on my site and, when saving it, it insists on
>>> trying to save it as .xht instead of .html. I have to manually
>>> change the file extension each time.
>> As I understand it, BlueGriffon will save with an .xht file extension
>> when a file has an XHTML doctype. So I suspect that's how your extra
>> page was created. If that's the case then...
>>> All the other pages are fine. Do you have any idea how to get this
>>> one page to use .html as the default when saving, please?
>> Open one of your other pages, which I assume will be of an HTML4
>> doctype, switch to source view and copy the DOCTYPE line there, then
>> switch to your extra page and paste over its doctype line with the one
>> you've copied.
>> As you switch out of source view, BlueGriffon will re-parse the page
>> converting all XHTML tags to HTML tags, and will in future save with a
>> .html extension.
>> Greg Chapman
>> http://www.gregtutor.plus.com >> Helping new users of KompoZer and The GIMP
>> Still exploring BlueGriffon
> Hi Greg,
> Thanks for the suggestion. Unfortunately, there is a problem. The code > returns a Parsing Error when pasted into the problem page. Any ideas, > please? the line I have copied and tried to paste is:-
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> On 24 Oct 12 06:53 Howard Neil <h.n...@which.net> said:
>> Can anyone please have a guess as to why I am getting this Parsing
>> Error, please?
> Maybe it's a case where we need to see the code, so we can see if we
> can reproduce your error?
> Greg Chapman
> http://www.gregtutor.plus.com > Helping new users of KompoZer and The GIMP
> Still exploring BlueGriffon
I am happy to let you see the code. What should I do? copy the whole of the code on the page where I am having the problem and paste it here? Or would you need the code for the other pages as well?
On 24 Oct 12 10:30 Howard Neil <h.n...@which.net> said:
> I am happy to let you see the code. What should I do? copy the whole
> of the code on the page where I am having the problem and paste it > here? Or would you need the code for the other pages as well?
Shouldn't need to see the code for the other pages, especially if only
one is affected.
Probably best to upload the page somewhere and post the URL, but if that's not possible then I guess the code pasted here would be OK.
> On 24 Oct 12 10:30 Howard Neil <h.n...@which.net> said:
>> I am happy to let you see the code. What should I do? copy the whole
>> of the code on the page where I am having the problem and paste it
>> here? Or would you need the code for the other pages as well?
> Shouldn't need to see the code for the other pages, especially if only
> one is affected.
> Probably best to upload the page somewhere and post the URL, but if
> that's not possible then I guess the code pasted here would be OK.
> Greg Chapman
> http://www.gregtutor.plus.com > Helping new users of KompoZer and The GIMP
> Still exploring BlueGriffon
The first thing I did was check the URL with the W3C validator. It shows 13 errors and one warning for the page. I had hoped that BlueGriffon's parser would automatically sort out such issues on saving the page, but obviously, it doesn't.
However, checking through the error list they are all because of the table containing your menu is not designed for HTML5. You definitely need the HTML4 TRANSITIONAL doctype for that code.
It is this that makes BlueGriffon present the .xht filetype on saving.
BlueGriffon normally generates:
<html>
for HTML doctypes.
I then saved the page locally and loaded it into BlueGriffon. It did not report a parse error and loaded normally, so I cannot reproduce the error you report.
However, I discovered that BlueGriffon will choke if you go to SOURCE view and attempt to edit the <html> line. It corrupts the page completely on return to WYSIWYG view. So the answer is you need to edit that line using an external text editor.
As for the cure for the page.
I'd tried creating a new HTML4 TRANSITIONAL page in BlueGriffon and then pasting in the bulk of your content in SOURCE view. That still left two validation errors. One resulting from the <style> code from the web buttons generator you used and the other related to the nested
tables you have used for page layout (Always a bad idea. Tables should
only be used for display of tabular data - in your case just the schedule of choir engagements).
I'm not sure if this is sufficient to help you get to the bottom of the problem, but it should go a fair way. Ideally, even for an HTML4 Transitional doctype you should be using CSS to control the layout of your page.
Not exactly. BlueGriffon generates that for HTML4 and html5 (HTML
serialization). It does generate add the xmlns attribute for
XHTML1 and html5 (xml serialization). That's required per spec.
> The first thing I did was check the URL with the W3C validator. It
> shows 13 errors and one warning for the page. I had hoped that
> BlueGriffon's parser would automatically sort out such issues on
> saving the page, but obviously, it doesn't.
> However, checking through the error list they are all because of the
> table containing your menu is not designed for HTML5. You definitely
> need the HTML4 TRANSITIONAL doctype for that code.
> It is this that makes BlueGriffon present the .xht filetype on saving.
> BlueGriffon normally generates:
> <html>
> for HTML doctypes.
> I then saved the page locally and loaded it into BlueGriffon. It did
> not report a parse error and loaded normally, so I cannot reproduce
> the error you report.
> However, I discovered that BlueGriffon will choke if you go to SOURCE
> view and attempt to edit the <html> line. It corrupts the page
> completely on return to WYSIWYG view. So the answer is you need to
> edit that line using an external text editor.
> As for the cure for the page.
> I'd tried creating a new HTML4 TRANSITIONAL page in BlueGriffon and
> then pasting in the bulk of your content in SOURCE view. That still
> left two validation errors. One resulting from the <style> code from
> the web buttons generator you used and the other related to the nested
> tables you have used for page layout (Always a bad idea. Tables should
> only be used for display of tabular data - in your case just the
> schedule of choir engagements).
> I'm not sure if this is sufficient to help you get to the bottom of
> the problem, but it should go a fair way. Ideally, even for an HTML4
> Transitional doctype you should be using CSS to control the layout of
> your page.
using Komposer bearing in mind your suggestion that there may be a problem in bluegriffon. Komposer removed that line and presented it as an html file when saved. However, when I reloaded the file (in either bluegriffon or Komposer) that line re-appeared.
I checked the file again in Komposer and the file is presented as an html file in the save window even with that line in. It seems that the problem may be in bluegriffon. However, the other pages save correctly so perhaps it is just a later edition bluegriffon.
>> The first thing I did was check the URL with the W3C validator. It
>> shows 13 errors and one warning for the page. I had hoped that
>> BlueGriffon's parser would automatically sort out such issues on
>> saving the page, but obviously, it doesn't.
>> However, checking through the error list they are all because of the
>> table containing your menu is not designed for HTML5. You definitely
>> need the HTML4 TRANSITIONAL doctype for that code.
>> It is this that makes BlueGriffon present the .xht filetype on saving.
>> BlueGriffon normally generates:
>> <html>
>> for HTML doctypes.
>> I then saved the page locally and loaded it into BlueGriffon. It did
>> not report a parse error and loaded normally, so I cannot reproduce
>> the error you report.
>> However, I discovered that BlueGriffon will choke if you go to SOURCE
>> view and attempt to edit the <html> line. It corrupts the page
>> completely on return to WYSIWYG view. So the answer is you need to
>> edit that line using an external text editor.
>> As for the cure for the page.
>> I'd tried creating a new HTML4 TRANSITIONAL page in BlueGriffon and
>> then pasting in the bulk of your content in SOURCE view. That still
>> left two validation errors. One resulting from the <style> code from
>> the web buttons generator you used and the other related to the nested
>> tables you have used for page layout (Always a bad idea. Tables should
>> only be used for display of tabular data - in your case just the
>> schedule of choir engagements).
>> I'm not sure if this is sufficient to help you get to the bottom of
>> the problem, but it should go a fair way. Ideally, even for an HTML4
>> Transitional doctype you should be using CSS to control the layout of
>> your page.
> using Komposer bearing in mind your suggestion that there may be a > problem in bluegriffon. Komposer removed that line and presented it as > an html file when saved. However, when I reloaded the file (in either > bluegriffon or Komposer) that line re-appeared.
> I checked the file again in Komposer and the file is presented as an > html file in the save window even with that line in. It seems that the > problem may be in bluegriffon. However, the other pages save correctly > so perhaps it is just a later edition bluegriffon.
