headers
Neil Hodgson | 1 Nov 2003 01:28
Picon

Re: Exporters overhaul

Philippe:

> I just finished a major Exporters.cxx overhaul...

   A very large change! Maybe this is the right opportunity to split the
file up...

   A couple of small problems: there is a need for a .c_str() at the end of
fprintf(fp, RTF_FONTDEF, 0, characterset, defaultStyle.font);
   The StyleDefinition constructor should initialise the fields in the same
order as they are defined.

   I'm not totally happy about including the fore and back information in
StyleDefinition twice, once as a string and once as a number as that could
lead to desynchronisation although individual StyleDefinition fields aren't
currently being updated individually I think.

   The code is committed with the minor fixes above and available from
http://www.scintilla.org/scite.zip Source
http://www.scintilla.org/wscite.zip Windows executable

   Hopefully people interested in particular output formats will check the
results.

   Neil
Permalink | Reply | 0 comments |
headers
Neil Hodgson | 1 Nov 2003 02:45
Picon

Re: Bug or my problem?

Robert Tyrakowski:

> Here the screen-shot of the error message.
>
> I tried V 1.56, but also the same result.
>
> The Make lines "del $(NAME).elf" and "ren $(NAME) $(NAME).elf"
> causes the same problem.
>
> Any idea ?

   Possibly some of the tools don't like being run from under a GUI
application rather than a command line application. Try changing the version
of make or getting an alternative make. Borland's free tools have an OK make
as does mingw. Digital Mars has a more primitive make.

   Neil
Permalink | Reply | 0 comments |
headers
Neil Hodgson | 1 Nov 2003 02:48
Picon

Re: scite156 solaris sparc

   Hi Marco,

> The program 'SciTE' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadAlloc (insufficient resources for operation)'.
>   (Details: serial 2723 error_code 11 request_code 53 minor_code 0)
>   (Note to programmers: normally, X errors are reported asynchronously;
>    that is, you will receive the error a while after causing it.
>    To debug your program, run it with the --sync command line
>    option to change this behavior. You can then get a meaningful
>    backtrace from your debugger if you break on the gdk_x_error()
function.
>
> any further hints except compiling gdb and check this out ;-)

   Someone else reported that but I haven't been able to reproduce it.
   Yes, it is time to run gdb and use --sync. Reporting a backtrace may
help. Also try with a current prerelease from CVS or
http://www.scintilla.org/scite.zip

   Neil
Permalink | Reply | 3 comments |
headers
Neil Hodgson | 1 Nov 2003 02:52
Picon

Re: Ctrl-Fn problem on Linux and suggestions for Windows

Tanel Tammet:

> I am using Scite 1.54 on sorcerer Linux,
> and have the same problem. On earlier versions of
> Scite (pre-tabbed-interface) the Ctrl-F2 worked
> just fine. Hence it does not seem to be related
> to 1.55 or Red Hat, but rather (I guess) the changes
> introduced for adding the tab windows on Linux.

   At that time the default build changed from GTK+ 1 to GTK+ 2 which is a
more likely cause than the tab bar.

> A slightly inconvenient ascpect of the
> Windows version is that the number of buttons on the
> button bar is much smaller than the number of buttons
> on Linux versions.

   If someone wants to do the work, including finding some button images
either from Windows or with very open licensing.

> Additional aspect: it would be
> real convenient to have the Windows version be
> as similar as possible to the Linux version.

   This requires someone to put in the effort to fill in the missing
features. Most contributors only run one environment so only implement for
that environment.

   Neil
(Continue reading)

Permalink | Reply | 0 comments |
headers
Philippe Lhoste | 1 Nov 2003 08:56
Picon

Re: Exporters overhaul

> > I just finished a major Exporters.cxx overhaul...
> 
>    A very large change! Maybe this is the right opportunity to split the
> file up...

Why not, but the file is still quite small, so I don't feel a urge here...

>    A couple of small problems: there is a need for a .c_str() at the end
of
> fprintf(fp, RTF_FONTDEF, 0, characterset, defaultStyle.font);

Oops, I get usually at least a warning at theses...

>    The StyleDefinition constructor should initialise the fields in the
same
> order as they are defined.

Really? Is this C++ specification? I ignored or forgot it.

>    I'm not totally happy about including the fore and back information in
> StyleDefinition twice, once as a string and once as a number as that could
> lead to desynchronisation although individual StyleDefinition fields
aren't
> currently being updated individually I think.

Well, the best solution may be so store the data as string, and convert it
on the fly when needed.
It would be less confusing and cleaner. I just didn't wanted to disturb the
regular use of this class, but as 
its uses seems limited, perhaps we can make the change (me or you?) and drop
(Continue reading)

Permalink | Reply | 1 comment |
headers
K. H. Man | 1 Nov 2003 18:01
Picon

Re: Exporters overhaul

Hi all,

Darren Schroeder wrote:
> I'd be interested in your comments.

The first thing is to create a class for tracking PDF objects,
without which the xref table cannot be built. Acrobat Reader can
rescan the PDF and rebuild the table but Ghostscript cannot. The
class also allocates object reference numbers dynamically.

After that it's a matter of doing the file structure right, then
the PDF operators as well. The original output is still mostly
correct, so fixing it is not difficult. I've added page references
in my code to the material in the PDF 1.4 Reference Manual. A
second class builds the PDF according to this hierarchy:
char -> segment -> line -> page -> file.

I've sent a preliminary fixed PDF exporter to Neil and Phillipe.
Trying to make it useful but not too large or complex, so it is
sort of a balancing act in terms of features/functionality.

Some preliminary results:
Exporters.cxx         46665
1.56 PDF exporter    517013
1.56 RTF exporter    157391
New PDF exporter     227692
After GS pdfwrite     75499
--

-- 
Cheers,
Kein-Hong Man (esq.)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Neil Hodgson | 1 Nov 2003 23:32
Picon

Re: Re: cache.layout when wrapping not turned on

   Hi Bruce,

> Perhaps a setting that lets you reduce the cache level
> based on the wrapping mode, without necessarily turning it off completely,
> would be useful even for GTK?

   There may be things that could be achieved here but they don't look all
that interesting to me. Where there is a speed decrease from more caching,
that should be looked at.

   Neil
Permalink | Reply | 2 comments |
headers
Neil Hodgson | 2 Nov 2003 00:27
Picon

Re: Exporters overhaul

Philippe Lhoste:

> >    The StyleDefinition constructor should initialise
> > the fields in the same order as they are defined.

> Really? Is this C++ specification? I ignored or forgot it.

   I don't know but gcc doesn't like it. I'm not sure what is being
protected against here: maybe some compilers ignore the names in the
construction list and assign the values to fields in order instead :-(

> Well, the best solution may be so store the data as string,
> and convert it on the fly when needed.

   OK, I have changed it. Available from CVS and aforementioned locations.

   Neil
Permalink | Reply | 0 comments |
headers
Neil Hodgson | 2 Nov 2003 00:48

Whitespace character setting

   Roy Wood has contributed an enhancement to Scintilla and SciTE that
allows more control over word movement. Scintilla defines 4 classes of
character for word selection, word characters, punctuation, white space, and
new lines. The defaults are for new lines to be Line Feed or Carriage
Return, white space to be Space or Tab or a control character, word
characters to be a-zA-Z0-9_ and non-ASCII with punctuation being those
characters left over.

   Scintilla has a SCI_SETWORDCHARS call which is exposed in SciTE as
word.characters.<filepattern> that allows the set of characters in the word
class to be changed. Sometimes it may also be desired to treat punctuation
as spaces and so cause the word movement keys to move past them. This
reduces the number of key presses to navigate. Scintilla has a
SCI_SETWHITESPACECHARS call to allow this and it is exposed in SciTE as
whitespace.characters.<filepattern>.

   The API may change a little befre release with an explicit way to reset
to defaults.

Available from CVS and from
http://www.scintilla.org/scite.zip Source
http://www.scintilla.org/wscite.zip Windows executable

   Also includes recent changes to file export.
   line.margin.visible property controls initial viibility of line margin
indenpendently to width setting.
   A small change to building SciTE on GTK+ with a user defined prefix
directory should install more files into the prefix directory.

   Neil
(Continue reading)

Permalink | Reply | 0 comments |
headers
Itschy | 2 Nov 2003 12:35
Picon

Re: Whitespace character setting

Hi Neil.

Am 02.11.2003 00:48 schrieb Neil Hodgson:
> ...word characters to be a-zA-Z0-9_ and non-ASCII with punctuation
 > being those characters left over.
> 
>    Scintilla has a SCI_SETWORDCHARS call which is exposed in SciTE as
> word.characters.<filepattern> that allows the set of characters in the word
> class to be changed. 

Great!
Would it be possible to add some non-ASCII-characters with "umlaut", 
such as ä,ö,ü,â,é etc. by default?

Thank you.

itschy
Permalink | Reply | 2 comments |

Gmane