[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-bugs-dist
Subject: Bug#30619: KDE Bug #30619 (Not all HTML files correctly opens from Kword)
From: Nicolas Goutte <nicog () snafu ! de>
Date: 2001-08-16 23:16:20
[Download RAW message or body]
On Thursday, 16. August 2001 10:02, Info wrote:
> 15 Август 2001 23:57, ы написали:
>
> Thanks.
>
> But it seemed to me that it is possible immediately increase KWord's
> usability with HTML filter without adding new features to filter. My
> view to the way of solving of this problem is in letter I sent to
> David Faure (followed). Of course, such solution is palliative, and
> full fonctionability will not be reached - but users of will can work
> as minimum with all simple HTML file. It's better than nothing.
>
>
> ________________________________________________________
> Дата: Wed, 15 Aug 2001 17:16:55 +0400
> Отправитель: Info <arling@sniip.ru>
> Получатель: "David Faure" <david@mandrakesoft.com>
>
>
> Hello, David!
>
> Now I mage bugreport 30619, and autogenerated reply says me that it
> is forvarded to you.
>
> Repeat bug: when no "charset=" is in <meta> tag in <head> section of
> HTML (webmasters often do such files), Kword uncorrectly opened this
> file ("???" instead of russian letters).
>
> Some remarks, as I see the solving of this problem.
>
> On my mind, it's need to check <meta> tags (in <head> section of
> file) for existant of string "charset="
>
> If this string exists, all is OK, and it's not needed to do nothing
>
> If no, then it's usable to establish some dialog:
> 1. Ask user - what encoding he expected of this file? It will be
> good, if some initial value of encoding will be setted (this value
> user will correct, if want). As this initial - default encoding from
> Konqueror's settings or from locale)
I had thought about a dialog before the filter parses the file. The problem
is that the user must also have the possibility to force an encoding if he
knows that the encoding written in the file is wrong (or not usable on his
system.)
> 2. Open file with initial (or corrrected by user) encoding, and ask
> again - it is correct ? (yes-no)
I cannot do that! The filter returns to KWord before KWord displays anything!
> 3. If no - return to step 1.
>
> > Thank you for the bug report!
> >
> > I am sorry but KWord's HTML import filter is not supposed to work
> > at all (see also http://www.office.org/filters/status.phtml .)
> >
> > The possibility of forcing an encoding for the import is already on
> > the TO-DO list of the filter (look at the status page of KWord's
> > HTML filter.)
> >
> > I am decreasing the severity of this bug report to "wishlist".
> >
> > Have a nice day/eveninig/night!
> >
> > >--- Original Bug Report ---
> > > Date: 15 Aug 2001 12:41:06 -0000
> > > Subject: Not all HTML files correctly opens from Kword
> > > From: 5740 at mail.ru
> > >
> > >
> > >Package: kword
> > >Version: 1.1 (RC1) (using KDE 2.1.2 )
> > >Severity: normal
> > >Installed from: ALT Linux Sisyphus
> > >Compiler: gcc version 2.96 20000731 (ALT Linux Sisyphus)
> > >OS: Linux 2.2.19-alt1-smp-secure i686
> > >OS/Compiler notes:
> > >
> > >As you know, not all webmasters set encoding in heads of their
> > > HTML files. It's bad practice, of course, but it exists.
> > >
> > >It caused that KWord can'd propertly display non-latin letters in
> > > such caved HTML files, when user try to open them with KWord.
> > >
> > >For example: go to www.nns.ru in Konqueror, save pened page
> > > somewhere (by drag-n-drop "Address" mark, for ex.), and try to
> > > open this html file with KWord. You will see "?????" instead of
> > > russian letters.
> > >
> > >As soon I will receive bug number of this message, I'l sent as
> > > additional message with attach such HTML file that doesn't opened
> > > with KWord
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic