Text alignment? Compatibility beween WPF & WPF/E RRS feed

  • Question

  • Is there a reason TextAlignment isn't supported for the TextBlock element?

    If so, I hope the reason is simply a matter of "not yet implemented", since I believe this to be an important feature that needs to be supported for the first release.  Particularly when wrapping is involved, this is something that needs to be provided by the basic text rendering functionality.

    Thursday, February 22, 2007 3:29 PM


  • No, we will not be having text alignment for a while. You'll have to split up your lines and manually center them.

    Program Manager
    This post is provided "as-is"

    Wednesday, February 28, 2007 8:16 PM

All replies

  • It is not yet implemented. However, you can center it using a little javascript and the ActualWidth property of the TextBlock.
    Thursday, February 22, 2007 11:49 PM
  • No, I can't -- particularly when wrapping is involved.  Imagine a labeled icon like you find on the Windows desktop.  Or something that should wrap as follows:




    Friday, February 23, 2007 12:02 AM
  • No, we will not be having text alignment for a while. You'll have to split up your lines and manually center them.

    Program Manager
    This post is provided "as-is"

    Wednesday, February 28, 2007 8:16 PM
  • OK, but I think these and other differences from WPF make WPF/E nearly unusable.

    I might play some more with WPF/E, but I intend to stop doing any development for WPF/E until it supports a realistic subset of WPF XAML.

    Wednesday, February 28, 2007 10:49 PM
  • Can you describe you application/scenario for centering lines of wrapped text? Also I'd like to understand why you can't have multiple <TextBlock> elements and programmatically calculating the center point.

    Program Manager
    This post is provided "as-is"

    Wednesday, February 28, 2007 11:33 PM
  • Imagine trying to implement Windows desktop icons.  You want the text to be centered and wrap automatically.  You also want to be able to trim it by limiting the height of the text to two lines.

    It isn't that I couldn't implement this myself.  It's just that it's already supported in GDI+ and (particularly) in WPF/XAML.  And implementing this myself does take effort -- a bunch of JavaScript, especially if I want it to handle all kinds of text.

    I think for WPF/E to be successful it needs to implement as complete and compatible a subset of WPF/XAML as possible.  It ought to be well defined in programmers' minds as "the same as WPF except for A,B,C and D".  Everyone can understand if you don't implement some kinds of elements because of resource or platform limitations.  But specifying the differences between the XAML schemas ought to be a simple, short list of missing elements and attributes.

    And of course limiting the differences will encourage tools, as well as developers, to support both platforms.

    Now I'm sure you already know these things, so I'd like to know what the design philosophy is, and why.

    Thursday, March 1, 2007 2:08 PM
  • I think for WPF/E to be successful it needs to implement as complete and compatible a subset of WPF/XAML as possible.

    If this was the goal we would have a 30 MB download for a plugin and a user base of almost zero. I think the goal is to add as much as possible while still keeping the size of the install at a minimum. I believe this is what the team is doing and part of the CTP process is seeing if they got the mix of features-to-size correct. They will probably not be able to make everyone happy since they are going to be forced to leave some things out.

    Just my $.02.


    Thursday, March 1, 2007 6:12 PM
  • Note that the WPF/E SDK contains an XSD that you can use to know what is supported and what isn't. As much as possible we are "the same as WPF except for..." In this case the except for is TextAlignment.

    Program Manager
    This post is provided "as-is"

    Thursday, March 1, 2007 7:57 PM
  • Ah, but why did you choose to leave out support for TextAlignment, when doing so is relatively simple and a small amount of code?

    And why did you choose to leave out support for displaying GIF files?

    Again, I'm looking to understand what the goals are, so that I can understand the tradeoffs and justification for missing features.

    Friday, March 2, 2007 11:39 AM

    Our philosophy is to enable as broad a set of customers scenarios as possible with the smallest runtime and exposing the smallest surface are possible.  For reach scenarios, we have to be small and agile to be successful and as such, we can release minimal broad surface area quicker, get feedback, and add layers on top of the minimal surface area only when necessary.  As a web platform, we cannot afford to be 60 MB and therefore have to reduce surface area down to the minimum required for customers.  We could have added both GIF and “TextAlignment” – but something else would have dropped off our feature list (we have limited time and resources).  For GIF, it may seem easy but in order to bring consistency to the platform, we bring our own decoders with us.  For GIF, not only does this add size to our platform, but it also requires a great deal of testing (there have been some large web security issues related to malformed image files).  So in the case of GIF, not only does this increase size, increase surface area (attack area for hackers) and take significant time,  it’s a bit redundant with our PNG support.  So rather than provide mostly redundant features at fairly high cost, we chose to do other features that offered greater customer value.  As for “TextAlignment”, this is not easy.  Dealing with measuring and arranging different fonts and font types across platforms is a fairly difficult problem.  Our goal was to enable text layout scenarios and we enabled the basic with TextBlock in conjunction with ActualHeight and ActualWidth.  We understand this isn’t ideal, but doing more takes time and effort and we’d rather get the bits into customers hands, determine where the pain points are, and then iterate.




    Sunday, March 4, 2007 3:44 AM
  • Thanks for the explanation.  I think your approach is reasonable, but I hope for WPF/E's sake that you are very sensitive to feedback suggesting that you may have missed some important features.  You never know when the success of a library/platform depends on the popularity of unheralded features.  Or what kind of reputation it gets that you spend years struggling to overcome.

    So I think if you were to document the list of image formats not supported by WPF/E that are supported by WPF, that would be a clear simple listing of the differences in functionality.  OK.

    But regarding TextAlignment, if it is not easy for you to implement, I doubt it would be easy for most of us developers to implement it repeatedly and correctly.  And yet I think there are a lot of applications where one would want centered & wrapped text.  Like most Windows desktops.

    I actually have implemented alignment and wrapping of text, on other platforms, so I'm familiar with the task.  It is a bit tricky, but it really isn't much code, so I don't think you would need to worry about adding megabytes to the download to support this feature.

    Although I have been asking for better documentation of the differences between WPF and WPF/E, I strongly suggest that you have a separate document (or chapter) describing the differences, both in overview and in detail.  Trying to understand the differences by looking at the XML schemas isn't very enlightening.

    Sunday, March 4, 2007 3:07 PM

    Our goal of frequent CTPs is to enable us to listen and incorporate customer feedback into the product.  We have heard feedback from other customers about the need for TextAlignment and are incorporating this in our product planning.


    Related to WPF, do you expect to actively develop for both platforms (WPF and WPF/E)?  Also, do you expect that you’ll ever share assets between the WPF and WPF/E and if so, what is your scenario for that?


    WPF was designed for a fidelity Windows experience and therefore has linkages to the Windows platform that are not easily removed (the text stack is an example of this).  It’s also powerful and complex and this does not necessarily translate into a small, agile everywhere platform that needs to scale from web to devices.  As such, differences will occur where the relationship may not be a pure subset relationship but rather a best for everywhere and a best for Windows that share a common core and a common set of tools.



    Sunday, March 4, 2007 5:53 PM
  • Yes, if I adopt WPF/E, I will actively develop for both platforms.  I would certainly expect to be able to share drawings via XAML.  I'm not expecting to share my custom event-handling code, obviously.  But very simple interactivity might work for both.

    It is analogous to sharing code between Windows Forms and Web Forms applications.  The "Forms" part of the application is quite different, but all the code behind those forms is basically the same.  But for WPF & WPF/E, I want to share the drawings as well as the lower-level code.

    By "drawings" I'm including 2D graphics, text, and media.  I hope you can understand how not supporting all the attributes I depend on would make it very difficult for me to use WPF/E as a platform.

    Monday, March 5, 2007 11:57 AM
  • >> do you expect that you’ll ever share assets between the WPF and WPF/E and if so, what is your scenario for that?

    When I first discovered WPF/E, this was my expectation. I develop a number of products that require both web and desktop versions and it was my hope that WPF/E would finally provide me with a model where I could share a whole lot more of my code base between these two environments. I'd like to have my designers generating XAML without any concern for whether the interface they design will be running in a browswer or as a desktop application. I want that to be entirely transparent. BTW, I need to achieve all of this without requiring my web clients to install the full .NET run-time (otherwise I'd just do XBAP and this wouldn't be a problem).

    I think there's a relatively large population of developers out here who really want WPF/E to be a tool that we can use to build information system. That means supporting text alignment, grids, buttons, combos, user controls, custom controls, and all the staples I have available to me with WinForms/WebForms. Now, what I'm hearing is that it may be unrealistic to expect WPF/E to take on this functionality without becoming too large. Ultimately, I could imagine you saying: "by the time we add all that functionality, the download would be as large as footprint of the entire framework." And, if that's the case, I'll undertand and I'll re-adjust my expectations for WPF/E.

    We're all out here just trying to figure out how much functionality WPF/E will ultimately support to determine how--or if--we should leverage it for our solutions. For me, I'm looking at Flex and some of the other RIA frameworks that provide all the elements I need, while still holding out hope that WPF/E might add the funtionality I'm looking for. I don't really want to have separate frameworks from separate vendors for my desktop and web solutions, but I'm also not sure I'll have a choice if WPF/E isn't expected to bite off this broader set of features. Either that, or I'm back to ASP.NET and trying to weave together some combination of elements that still give me the "snappy" user experience I'm after.

    Is there any chance that someone at MS will make a more definitive statement about the long-term plans for WPF/E? Will it take on the broader role or will it be allowed to grow enough in size to give us all the building blocks we need to start assembling complete applications? Any insight that helps clarify this would be appreciated.



    Wednesday, March 7, 2007 6:19 PM