- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [pharo-project/pharo-core] de6e0a: 50003

by Yuriy Tymchuk

So now startup actions are not working because StartupLoader was removed. What are the plans about this? > On 21 Apr 2015, at 17:40, GitHub <noreply(a)github.com> wrote: > > Branch: refs/heads/5.0 > Home: https://github.com/pharo-project/pharo-core > Commit: de6e0a2db24ff07aaa850ca0fbea53e8860cbb0e > https://github.com/pharo-project/pharo-core/commit/de6e0a2db24ff07aaa850ca0… > Author: Jenkins Build Server <board(a)pharo-project.org> > Date: 2015-04-21 (Tue, 21 Apr 2015) > > Changed paths: > A AST-Core.package/NumberParser.class/class/testing/isNumber_.st > A AST-Tests-Core.package/NumberParserTest.class/instance/tests - Float/testIsNumber.st > R Deprecated40.package/NBWin32Caret.class/README.md > R Deprecated40.package/NBWin32Caret.class/class/accessing/getBlinkTime.st > R Deprecated40.package/NBWin32Caret.class/definition.st > R Deprecated40.package/NBWin32Menu.class/README.md > R Deprecated40.package/NBWin32Menu.class/definition.st > R Deprecated40.package/NBWin32MessageBox.class/README.md > R Deprecated40.package/NBWin32MessageBox.class/class/instance creation/messageBox_text_title_flags_.st > R Deprecated40.package/NBWin32MessageBox.class/class/instance creation/test.st > R Deprecated40.package/NBWin32MessageBox.class/definition.st > R Deprecated40.package/NBWin32Process.class/README.md > R Deprecated40.package/NBWin32Process.class/class/accessing/getCurrentProcess.st > R Deprecated40.package/NBWin32Process.class/class/accessing/getCurrentProcessId.st > R Deprecated40.package/NBWin32Process.class/definition.st > R Deprecated40.package/NBWin32Process.class/instance/accessing/getPriorityClass.st > R Deprecated40.package/NBWin32Process.class/instance/testing/isHighPriorityClass.st > R Deprecated40.package/NBWin32Process.class/instance/testing/isIdlePriorityClass.st > R Deprecated40.package/NBWin32Process.class/instance/testing/isNormalPriorityClass.st > R Deprecated40.package/NBWin32Process.class/instance/testing/isRealtimePriorityClass.st > R Deprecated40.package/NBWin32ShellTest.class/README.md > R Deprecated40.package/NBWin32ShellTest.class/definition.st > R Deprecated40.package/NBWin32ShellTest.class/instance/tests/testGetCommandLine.st > R Deprecated40.package/NBWin32ShellTest.class/instance/tests/testGetComputerName.st > R Deprecated40.package/NBWin32ShellTest.class/instance/tests/testGetDriveType.st > R Deprecated40.package/NBWin32ShellTest.class/instance/tests/testNoDebuggerPresentByDefault.st > R Deprecated40.package/NBWin32ShellTest.class/instance/tests/testNumberOfProcessors.st > R Deprecated40.package/NBWin32Thread.class/README.md > R Deprecated40.package/NBWin32Thread.class/class/accessing/getCurrentThread.st > R Deprecated40.package/NBWin32Thread.class/class/accessing/getCurrentThreadId.st > R Deprecated40.package/NBWin32Thread.class/definition.st > R Deprecated40.package/NBWin32Thread.class/instance/testing/isThreadAllAccess.st > R Deprecated40.package/Password.class/README.md > R Deprecated40.package/Password.class/definition.st > R Deprecated40.package/ShadowLabelMorph.class/README.md > R Deprecated40.package/ShadowLabelMorph.class/definition.st > R Deprecated40.package/ShadowLabelMorph.class/instance/drawing/drawOn_.st > R Deprecated40.package/StartupLoader.class/README.md > R Deprecated40.package/StartupLoader.class/class/accessing/default.st > R Deprecated40.package/StartupLoader.class/definition.st > R Deprecated40.package/TimeStamp.class/README.md > R Deprecated40.package/TimeStamp.class/class/instance creation/now.st > R Deprecated40.package/TimeStamp.class/class/instance creation/readFrom_.st > R Deprecated40.package/TimeStamp.class/definition.st > R Deprecated40.package/TimeStamp.class/instance/printing/printOn_.st > R Deprecated40.package/TimeStamp.class/instance/squeak protocol/asTimeStamp.st > R Deprecated40.package/TimeStamp.class/instance/squeak protocol/species.st > R Deprecated40.package/TimeStamp.class/instance/squeak protocol/storeOn_.st > R Deprecated40.package/extension/CheckBoxModel/instance/whenLabelChanged_.st > R Deprecated40.package/extension/Class/instance/name_.st > R Deprecated40.package/extension/CompiledMethod/instance/messagesDo_.st > R Deprecated40.package/extension/Date/instance/leap.st > R Deprecated40.package/extension/DateAndTime/instance/asTimeStamp.st > R Deprecated40.package/extension/ImageModel/instance/whenActionChanged_.st > R Deprecated40.package/extension/ImageModel/instance/whenImageChanged_.st > R Deprecated40.package/extension/LabelModel/instance/text.st > R Deprecated40.package/extension/LabelModel/instance/text_.st > R Deprecated40.package/extension/LabelModel/instance/whenLabelChanged_.st > R Deprecated40.package/extension/LabelModel/instance/whenTextChanged_.st > R Deprecated40.package/extension/Locale/class/addLocalChangedListener_.st > R Deprecated40.package/extension/Locale/class/isoLocale_.st > R Deprecated40.package/extension/Locale/class/localeChanged.st > R Deprecated40.package/extension/Locale/class/localeChangedListeners.st > R Deprecated40.package/extension/LocaleID/class/previous.st > R Deprecated40.package/extension/Matrix/class/column_.st > R Deprecated40.package/extension/Matrix/class/row_.st > R Deprecated40.package/extension/MenuMorph/class/fromArray_.st > R Deprecated40.package/extension/MenuMorph/instance/addTranslatedList_.st > R Deprecated40.package/extension/MenuMorph/instance/addUpdating_action_.st > R Deprecated40.package/extension/MenuMorph/instance/addUpdating_target_action_.st > R Deprecated40.package/extension/MenuMorph/instance/add_action_.st > R Deprecated40.package/extension/MenuMorph/instance/add_target_action_.st > R Deprecated40.package/extension/MenuMorph/instance/title_.st > R Deprecated40.package/extension/MorphicUIManager/instance/request_initialAnswer_centerAt_.st > R Deprecated40.package/extension/NonInteractiveUIManager/instance/request_initialAnswer_centerAt_.st > R Deprecated40.package/extension/Object/instance/asReactiveVariable.st > R Deprecated40.package/extension/OldClassBuilderAdapter/instance/anonymousSubclassOf_.st > R Deprecated40.package/extension/OldClassBuilderAdapter/instance/becomeCompact_.st > R Deprecated40.package/extension/OldClassBuilderAdapter/instance/becomeCompact_simplyAt_.st > R Deprecated40.package/extension/OldClassBuilderAdapter/instance/becomeUncompact_.st > R Deprecated40.package/extension/PluggableTextMorphWithLimits/instance/ifLocked_.st > R Deprecated40.package/extension/PluggableTextMorphWithLimits/instance/ifLocked_ifUnlocked_.st > R Deprecated40.package/extension/RGClassDefinition/instance/classSymbol.st > R Deprecated40.package/extension/RGMethodDefinition/instance/classSymbol.st > R Deprecated40.package/extension/RPackage/instance/correspondingMcPackage.st > R Deprecated40.package/extension/RPackageOrganizer/instance/renamePackage_in_.st > R Deprecated40.package/extension/RadioButtonModel/instance/whenLabelChanged_.st > R Deprecated40.package/extension/Stream/instance/isMessageStream.st > R Deprecated40.package/extension/String/instance/asTimeStamp.st > R Deprecated40.package/extension/String/instance/do_toFieldNumber_.st > R Deprecated40.package/extension/String/instance/padded_to_with_.st > R Deprecated40.package/extension/String/instance/splitInteger.st > R Deprecated40.package/extension/String/instance/tabDelimitedFieldsDo_.st > R Deprecated40.package/extension/String/instance/withFirstCharacterDownshifted.st > R Deprecated40.package/extension/SystemAnnouncement/class/fromInternal_.st > R Deprecated40.package/extension/TClass/instance/classPoolFrom_.st > R Deprecated40.package/extension/TClass/instance/ensureClassPool.st > R Deprecated40.package/extension/ToolRegistry/instance/shortcuts.st > R Deprecated40.package/extension/ToolRegistry/instance/userManager.st > R Deprecated40.package/extension/UIManager/instance/displayProgress_at_from_to_during_.st > R Deprecated40.package/extension/UIManager/instance/request_initialAnswer_centerAt_.st > R Fuel.package/extension/TimeStamp/instance/fuelAccept_.st > R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script611.st > A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script612.st > R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50002.st > A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50003.st > M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > > Log Message: > ----------- > 50003 > 15330 NumberParser>>#isNumber: > https://pharo.fogbugz.com/f/cases/15330 > > 15368 unload Deprecate40 in Pharo5 > https://pharo.fogbugz.com/f/cases/15368 > > http://files.pharo.org/image/50/50003.zip > >

April 21, 2015

[Pharo5] All systems on go!

by Marcus Denker

Hi, So finally everything seems to work for getting going on Pharo5â¦ this means there will be regular at least one update per day (if issue are in the state of âfix to includeâ are available). Today I did #003 which included the unloading of the Deprecated package of the last version. Marcus

April 21, 2015

Re: [Pharo-dev] Roadmap

by Peter UhnÃ¡k

On Mon, Apr 20, 2015 at 7:26 PM, Dmitri Zagidulin <dmitri(a)zagidulin.net> wrote: > Similar question - are there any roadmap plans to add Dictionary literals > to Pharo? > You can already do things like { 'key' -> 'value'. 'key2' -> 'value2' } asDictionary

April 21, 2015

Re: [Pharo-dev] Recommended image resolution for Pillar books?

by Dmitri Zagidulin

Ahhh I see. I assumed the width params were in pixels. Thanks! On Tue, Apr 21, 2015 at 12:01 PM, Damien Cassou <damien.cassou(a)inria.fr> wrote: > > Dmitri Zagidulin <dmitri(a)zagidulin.net> writes: > > > How would one do that? Does the width attribute take HTML style > parameters > > (px, %)? > > in the Pillar chapter of EnterprisePharo, I give an example: > > +Caption of the picture>file://figures/pier-logo.png|width=50+ > > 50 means half of the line width. Currently, there is no way to specify > something in px. > > > https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > >

April 21, 2015

Re: [Pharo-dev] Improving the documentation model

by Dmitri Zagidulin

On Tue, Apr 21, 2015 at 12:15 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > I dream that all documents in my Dynabook are WYSIWYG. However, the > computing world seems to have regressed into writing documents in various > forms of assembly code. Completely disagree, that it's a regression in any way :) Text-based document writing has enabled so many more features than WYSIWYG approaches have ever dreamed of. I would be happy to debate the merits of the two approaches, feature-for-feature. You're basically pining for the equivalent of VisualBasic drag & drop programming, versus the flexibility of writing code in an editor. The latter wins, no contest. (Now, that is not to say that text-based code editing can't be /improved/ with better IDE tools, that's what we're all about after all.)

April 21, 2015

Center morph in a morph

by Yuriy Tymchuk

Hi, I guess this is similar to vertical css centering question :) Iâve tried to use: cellPositioning: #center; listCentering: #center; with TableLayout but morphs are still positioned at the top of parent morph. Can I somehow put them in the middle (vertically)? Uko

April 21, 2015

Re: [Pharo-dev] Roadmap

by Dmitri Zagidulin

On Tue, Apr 21, 2015 at 12:14 PM, Richard Sargent < richard.sargent(a)gemtalksystems.com> wrote: > > Please be careful of complicating the language syntax. Perhaps the better > solution is to improve the optimizer until it can recognize the fact that > the expression really is constant and can inline the generated code. > That's just implementation details :) (extending the language syntax vs pre-processing & inlining code). I don't care, as long as we eventually have the ability to do simple Dictionary literals (like we do with strings & arrays). > I had an interesting lesson in this just the other day from Martin McClure. > I had been asking for a feature like VA Smalltalk's "compile-time > constant". > I am now convinced that is not the way to go. > Can you elaborate on that more? What did Martin McClure say? (Why did you change your mind that a compile-time constant (I'm not sure what that is, actually) is not the way to go?)

April 21, 2015

Re: [Pharo-dev] [squeak-dev] RE: [Metacello] Re: [Vm-dev] Fixes to the SqueakSSL Plugin

by Ron Teitelbaum

> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of > David T. Lewis > > Thanks Ron, > > To confirm, I would like to be a contributor also. The rest of your list (Marcel, > Levente, Eliot and Esteban) are all good choices too. Hi David, I added you also. Thanks! Ron > > Dave > > > Ok that is done. > > > > I added Frank Shearar also. > > > > Anyone else that would like to be added as a contributor please let me > > know. > > > > Marcel Taeumel > > Levente Uzonyi > > David Lewis > > Eliot Miranda > > Estaban Lorenzano > > > > Seem like good choices but I wouldn't want to do it without their say so. > > > > All the best, > > > > Ron Teitelbaum > > > > > > -----Original Message----- > > > > > > On 21.04.2015, at 17:20, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> thank you very much! > >> I will merge it with our branch. > > > > Note that the platform-specific files are still dispersed over the > > vm-dev list. > > I will put them into Ron's squeakssl repo > > > >> > >> Esteban > >> > >>> On 21 Apr 2015, at 16:59, Tobias Pape <Das.Linux(a)gmx.de> wrote: > >>> > >>> > >>> Dear Smalltalkers > >>> > >>> Starting with Levente Uzonyi's patches to the Linux version of the > >>> SqueakSSL-Plugin, we (Marcel Taeumel and me) have ported this to the > >>> OS X and Windows version as well. > >>> > >>> Find three binaries[1] that can be used instead of the ones found on > >>> versions found on SqueakSSL's google code page. > >>> > >>> SqueakSSL: > >>> - x86 32bit Linux ELF dynamic library > >>> - Contains Levente's SNI feature > >>> - needs SqueakSSL-ul.29 or equivalent for SNI support > >>> - can work without. > >>> - NOT linked against OpenSSL, but > >>> _statically_ linked against LibreSSL 2.1.6 [2]. > >>> - It should work on older and newer Debian/Ubuntu as well as on > >>> CentOS/RedHat/SuSE systems. > >>> > >>> SqueakSSL.dll > >>> - x86 32bit Windows dll (built with Visual Studio 2013) > >>> - Uses Schannel API > >>> - SNI Support > >>> - needs SqueakSSL-ul.29 or equivalent for SNI support > >>> - can work without. > >>> - setting an Int property via sqSetIntPropertySSL(...) > >>> - Unicode problems when extracting the correct peerName in > >>> sqExtractPeerName > >>> > >>> SqueakSSL.bundle > >>> - x86 32bit OS X Mach-O dylib (Linked against OS X 10.5 SDK) > >>> - Uses Security-Framework > >>> - SNI Support > >>> - needs SqueakSSL-ul.29 or equivalent for SNI support > >>> - can work without. > >>> -------------------------------------------------------------------- > >>> - > >>> ------------ > >>> > >>> The changes necessary for Windows and OS X are not yet available in > >>> the squeakvm svn, the linux ones are. > >>> I have not yet found a good way to include the static linking in > >>> either the way the Autoconf works for Cog or CMake works for the > >>> interpreter, but I'll follow-up to this. > >>> > >>> -------------------------------------------------------------------- > >>> - > >>> ----------- > >>> > >>> Best regards > >>> -Tobias > >>> > >>> > >>> > >>> > >>> [1]: http://forum.world.st/file/n4820846/squeakssl.zip > >>> [2]: http://www.libressl.org/ > > > > > > > > > > > > > >

April 21, 2015

[ANN]: AconcaguaAddOns

by Sean P. DeNigris

I pushed some Aconcagua extensions to http://smalltalkhub.com/mc/SeanDeNigris/AconcaguaAddOns/main/ One part consists of tiny (so far) Aconcagua models of various domains - Time*, Money, and Weight at the moment. The other is the Aconcagua-Magritte package. This gives you MAMeasureDescription, which represents an Aconcagua Measure. It mostly acts like a number field mapped to its amount. You just have to tell it which unit to use to convert the amount number into a Measure. Example usage: MAMeasureDescription new accessor: #replacementPrice; label: 'Replacement Price'; unit: AmDollar new; yourself Then, you can type 100 in a Magritte form and "100 dollars" will be saved to the model. Enjoy! * Yes, I know Chalten has months and years, but (I think when Chalten was extended to handle non-Gregorian calendars) months and year units are no longer derived from each other, and so can not be compared. ----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-AconcaguaAddOns-tp4820940.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 21, 2015

Re: [Pharo-dev] Improving the documentation model

by Dmitri Zagidulin

I strongly believe that the WYSIWYG editing route is a fundamentally worse approach for documentation (and textbooks) than text-based formatting such as Pillar, Markdown and Asciidoc. Specifically, it will result in less community contribution, and it will make distributed version control of documents much harder. That said, I will support whatever documentation format or tech stack that the community adapts. Any documentation is better than none, regardless of the underlying details. (Though I will always advocate for text-based formats). Instead of going the route that you propose (which essentially attempts to Word or Google Docs in-image), I think we should: * Extend Pillar. With a few more features, it can be on par with Markdown and Asciidoc, and then eventually surpass it (and have nice Pharo-specific features like detection and unit-testing of Pharo code blocks, etc). * Invest in instant-preview tech, in-image. This is similar to what PillarHub does, for example, by using the Ace online editor. Take a look at the first screenshot in: http://pillarhub.pharocloud.com/hub/pillarhub/about Side-by-side instant preview makes it possible to have the best of both worlds, text-based markup and WYSIWYG, without the typical WYSIWYG drawbacks (of making distributed version control difficult, first and foremost). I will attempt to explain my reasoning, both for text-based markup, and against heavier WYSIWYG approaches. 1) With documentation (and textbooks), the number one goal and number one virtue is: make it easy for people to contibute. This means two things -- the simplicity of the format (this is where LaTeX fails), and the ease of distributed version control (merging, pull requests, reviews and commentary on contributions). Look at the explosion in community-generated documentation and content (READMEs on repos, the entirety of Wikipedia) that has resulted from *making it easy for people to contribute and edit collaboratively*. 2) Version control, especially with more than one or two collaborators, is a *nightmare* with WYSIWYG tools. Look at what the state of the art is, at what Microsoft's Word and Google's Docs have been able to accomplish, in terms of revision control. Despite unimaginable amounts of person-hours of development put into it, it's pretty much unusable (I speak from extensive personal experience, both from collaborating on technical and business documents using Word and Docs, and from seeing my wife and her friends (who are professional authors) struggle with Word's revision control systems while working with their publishers). We are not Microsoft or Google. We are not going to solve the WYSIWYG source control / version control problem better than they are. We need to focus where we spend our efforts. In contrast, text-based markup version control is a solved problem. 3) The convenience of WYSIWYG can be provided with side-by-side instant preview (again, see PillarHub and the numerous WYSIWYG instant-previews in Markdown editors). 4) The ability to render source text-based markup into multiple formats (PDF, HTML, etc), is *essential*. Going from WYSIWYG to HTML is impossible (all attempts to do so, by Microsoft, Adobe, etc, have utterly failed). Whereas going from text-based to print/PDF is very doable (see LaTeX, the entirety of HTML ecosystem, Pillar, etc). This is a serious problem that FrameMaker never had to solve. 5) Text-based markup is not primitive. You mention a comparison to HTML 1.0. This is apt, but in the opposite direction than you intend. 1.0 may have been primitive. But it has evolved into HTML 5, which not only has many semantics level content features, but is expressive enough that pretty much all UIs are moving to it (operating systems, desktop app suites, mobile devices, etc). Pillar may be in a primitive state right now, but it already has some decent semantics-level capability, and can have a lot more with considerably less effort than it would take to evolve WYSIWYG tools. And actually, the WYSIWYG approach is much closer to HTML 1.0 (in the sense that, users have to indicate *semantic* intentions like emphasis by selecting different fonts, versus something like HTML 4/5, where the actual intention is declared (EMPH tags, QUOTE tags, etc). 6) You mention the two standards in document writing (Word and LaTeX), and the drawbacks to each. I completely agree there. There is a third option, however, on which the world of open-source community technical writing is standardizing. And it involves text-based markup languages: * Markdown (in the form of https://www.gitbook.com/ ) * Asciidoc (more specifically, the Asciidoctor http://asciidoctor.org/ text processor and publishing toolchain). Take a look at https://medium.com/@chacon/living-the-future-of-technical-writing-2f368bd0a… for example. * Pillar (that's us). 7) Text-based markup formats (aside from LaTeX) actually possess all of the desired features that you mention, that are required to write book-length technical documentations. Something like Asciidoc already possesses them, and Pillar has most of them (and can be extended to have the rest). Let's take a look at some of them: * High-level publishing-centered semantic abstractions. In other words, both the concept of book sections, chapters, chapter sections, paragraphs, figures, etc, as well as the ability to compose a larger document out of smaller named documents: - Pillar and Asciidoc have chapters, sections, paragraphs, figures and named scripts/code blocks. - Asciidoc has the ability to do file imports (compose a larger document out of smaller docs) * Links. Asciidoc has semantic links both within a document, and across different Asciidoc documents (references to chapters, sections, etc). Pillar has within-document links, and inter-doc links are on the roadmap. * The ability to drop down to a more expressive markup (LaTeX or HTML). For heavier-duty features like formulas and equations, all of the simple markup languages allow the author to drop down to LaTeX and lay out formulas to their heart's content. 8) Text-based markup formats are much easier to both extend (add new semantic tags, etc) and to machine-process (parse, apply macros, etc) than WYSIWYG formats. So, in summary: - Text-based markup languages result in a lot more technical docs being written - Pillar can match or beat any of the WYSIWYG editor features, with not too much time and effort investment. On Tue, Apr 21, 2015 at 9:11 AM, stephan <stephan(a)stack.nl> wrote: > TL;DR: Some roadmap ideas. Looks like a lot of work. > Comments and improvements welcome: > We should replace the Pillar document format > by a better one, suitable for WYSIWYG editing and > creating long documents. > > --- > > The current documentation model for Pharo is Pillar. > Pillar is the document model from the Pier CMS and > provides exports to (a.o) html and LaTeX. It is a > simplified form of the LaTeX document model > without a WYSIWYG UI. > > In the research world two documentation systems > dominate: LaTeX and Word. Word and its clones > dominate areas where ease of use for small papers > without maths are important, LaTeX the other fields. > > From personal experience I know that the lack of > abstraction in Word and clones makes it very expensive > to create large, consistently formatted documents. > In addition, the typographical quality of the resulting > documents is much lower than that achievable with > LaTeX. > > On the other hand, repurposing LaTeX to generate > anything other than PDF/paper documentation is > difficult because of the underlying language that > LaTeX is written in, and there is no easy to use > WYSIWYG UI for LaTeX. > > It pains me to see the return of text based formatting > with primitive formats like markdown. At least in LaTeX > you can preserve semantics level content, in markdown > we are back at html 1.0. > > The program I liked best for creating longer documents > was Framemaker. That provided the needed abstractions > in an efficient WYSIWYG UI. Framemaker was sold > from 1986, so the performance of current hardware > should be enough to run something similar in smalltalk. > I used versions 5.5 and 6, and had to abandon it when > Adobe stopped development and it was never migrated > from PowerPC. > > Framemaker was fast enough to create books with > hundreds and even thousands of pages. It had working > versions of the long document features Word claimed to > have. > > With Athens and TxText we now have low level > abstractions for dealing with cursor and selection, fonts, > rendering glyphs and having both on-screen and > PDF output. > > On top of TxText we could add a model somewhat like > the attached figure > [image: UML diagram of document structure] > A book consists of a number of named documents. > This is essential for dealing with longer material, as > in a wysiwyg system we want to avoid having to re-layout > too much after a key is pressed. Across documents we only > need to remember the starting page/section numbers. > > Each document consists of pages. On a page there can be fixed > content and content that is dependent on the text flow. > Most pages of a document have a similar layout, so each page > refers to a masterpage that defines the default content. > A document can have separate masterpages for > first, left and right pages, and rotated or extra large ones. > A masterpage can define fixed items and calculated ones > (pagenumbers and current chapter). A textframedefinition > describes the textframes and the textflow for each textframe. > > The text (and other in-line contents) of the document are stored > in paragraphs, which are stored in textflows. > The paragraphstyle of a paragraph knows how to layout it in > a textframe, and how to deal with the end of a textframe. > The paragraphstyle knows how to paginate, how to number > or provide other autotext at the beginning of a paragraph and > if the paragraph text should be part of a table of contents. > A textframe is a (rectangular) area on a page. > The characterstyle of a paragraph is responsible for the font family, > size and style. The characterstyle can be overridden > by a specific paragraph or by a textrange. > > With a model like this (and adding maths, tables, notes, figures > and references) we should be able to use Pharo to create both > high-quality documentation, and write research articles > (and books) in-image. > > Stephan > > > > >

April 21, 2015